AI22-0089-1

!standard 8.6(18)                                    24-04-24  AI22-0089-1/05

!standard 9.1(19/2)

!standard 9.1(20)

!standard 9.4(21/2)

!standard 9.4(22)

!standard 9.5(3/3)

!standard 9.5(8)

!standard 9.5.1(2)

!standard 9.5.1(21)

!class Binding Interpretation 23-12-07

!status Amendment 1-2022  23-12-14

!status WG9 Approved 24-06-10

!status ARG Approved  11-0-0  23-12-14

!status work item 23-12-07

!status received 23-12-07

!submitter Randall Brukardt

!priority Low

!difficulty Easy

!qualifier Omission

!subject Current Instance for Single Task/Protected Objects

!summary

The definition of current instance is extended to cover the single_task_declaration and single_protected_declaration constructs.

!issue

The notion of current instance is defined for task and protected types, but not for single task and protected objects. However the term is used in 9.1, 9.4, 9.5, and 9.5.1 to talk about the “current instance” of a task or protected unit. Should we extend the definition of current instance to cover these cases? (Yes.)

!recommendation

(See summary.)

!wording

Modify AARM 8.6(17.a/2):

Reason: This is needed, for example, for references to the Access attribute from within the type_declaration. Also, within a task_body or protected_body, we need to be able to denote the current task or protected object.[ (For a single_task_declaration or single_protected_declaration, the rule about current instances is not needed.) ]We exclude anonymous access types so that they can be used to create self-referencing types in the natural manner (otherwise such types would be illegal).

Add immediately before 8.6(18):

!discussion

It could be argued that there is no need to talk about a current instance for these singleton constructs, since a name that denotes such a singleton declaration already denotes the entity declared by the construct. However, wording in 9.1, 9.4, 9.5, and 9.5.1 would be made more complex by treating these singletons as a special case. (See the !standard headers above for a list of the specific paragraphs that use the current instance definition and expect that to cover singleton tasks and protected objects.) So it was felt to be simpler to simply define the current instance to be the already denoted entity, rather than having to add “(or singleton task/protected object)” in multiple places.

We added the new paragraph before the paragraph on the current instance of a generic, as this new case involves a current instance which is an object, corresponding to the immediately preceding paragraphs.

!example

An example of where this becomes relevant is in the rule for whether the components of a protected object can be updated during a protected operation. RM 9.5.1(2) says:

Within the body of a protected function (or a function declared immediately within a protected_body), the current instance of the enclosing protected unit is defined to be a constant (that is, its subcomponents may be read but not updated).

protected Counter is
   function Value return Integer;
   procedure Bump;
private
   Count : Integer := 0;
end Counter;

protected body Counter is
   function Value return Integer is
   begin
      return Counter.Count;  --  "Counter" denotes R/O current instance
   end Value;
   . . .
end Counter;

 

By giving the term current instance a meaning in this context, the same set of rules can be used for protected types and single protected objects. A corresponding benefit is provided for single tasks.

!corrigendum 8.6(17.1/5)

@dinsa

@xindent{Within an @fa{aspect_specification} for a type or subtype, the current instance represents a value of the type; it is not an object. Unless otherwise specified, the nominal subtype of this value is given by the subtype itself (the first subtype in the case of a @fa{type_declaration}), prior to applying any predicate specified directly on the type or subtype. If the type or subtype is by-reference, the associated object of the value is the object associated (see @ref{6.2}) with the evaluation of the usage name.}

@dinst

@xbullet{If a usage name appears within the declarative region of a @fa{single_task_declaration} (or respectively, a @fa{single_protected_declaration}) and it denotes that same @fa{single_task_declaration} (respectively @fa{single_protected_declaration}), then it denotes the @i{current instance} of the task unit (respectively protected unit), which in this case is the object declared by the unit. See also @ref{9.1} and @ref{9.5}.}

!ACATS test

No additional ACATS tests are needed, existing tests already assume that the rules apply to single tasks and protected objects.

!appendix