Version 1.2 of ai12s/ai12-0406-1.txt

Unformatted version of ai12s/ai12-0406-1.txt version 1.2
Other versions for file ai12s/ai12-0406-1.txt

!standard 3.10.2(3/2)          20-12-01 AI12-0406-1/02
!standard 3.10.2(18)
!standard 3.10.2(19/3)
!standard 3.10.2(19.1/3)
!standard 7.6.1(3/2)
!class binding interpretation 20-11-20
!status work item 20-11-20
!status received 20-11-20
!priority Low
!difficulty Easy
!qualifier Clarification
!subject Clarifying static accessibility
!summary
The term "master construct" is introduced to clarify the static meaning of master (as used to define the "statically deeper" relationship).
The statically deeper relationship does not apply to types declared in generic formal packages.
!question
(1) While researching another question, issues were raised with the use of masters in the definition of statically deeper, used for accessibility Legality Rules. "Master" is defined to be a dynamic concept, being the execution of certain constructs (see 7.6.1(3/2)). Statically deeper is defined in terms of this dynamic concept, something that is noted in the AARM as being dubious.
One effect of this is that a construct defined in a generic unit can never have a master, since a generic unit is never executed (an instance of a generic unit can be executed, but that's a different unit). As such, the language, strictly speaking, does not define any static accessibility checks in generic units. This does not match typical practice nor intuition. Should these definitions be reworded? (Yes.)
(2) Types declared in a generic formal package act much like generic formal types themselves. However, the "statically deeper" rules do not treat these in the same way as generic formal types. This means that operations using such types can be rejected even when there is no problem -- see
!example for such a case. Should this be corrected? (Yes.)
!recommendation
(See Summary.)
!wording
The changes to 3.10.2(19/3-19.1/3) are needed for question (2), the other changes are needed for question (1).
Modify 3.10.2(3/2):
[The accessibility rules, which prevent dangling references, are written in terms of /accessibility levels/, which reflect the run-time nesting of /masters/. As explained in 7.6.1, a master is the execution of a certain construct {(called a /master construct/)}, such as a subprogram_body. An accessibility level is ...
Modify 3.10.2(18):
For a master {construct} that is statically nested within another master {construct}, the accessibility level of the inner master {construct} is statically deeper than that of the outer master {construct}.
Delete AARM 3.10.2(18.a). [We're now talking about constructs.]
Replace 3.10.2(19/3-19.1/3): [Note: The third paragraph here comes from AI12-0392-1]
The statically deeper relationship does not apply to the accessibility level of the anonymous type of an access parameter specifying an access-to-object type nor does it apply to a descendant of a generic formal type; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other.
The statically deeper relationship does not apply to the accessibility level of the type of a stand-alone object of an anonymous access-to-object type; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other.
The statically deeper relationship does not apply to the accessibility level of a raise_expression; that is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other.
with:
The statically deeper relationship does not apply to the accessibility level of the following:
* the anonymous type of an access parameter specifying an access-to-object type;
* the type of a stand-alone object of an anonymous access-to-object type;
* a raise_expression;
* a descendant of a generic formal type;
* a descendant of a type declared in a generic formal package.
That is, such an accessibility level is not considered to be statically deeper, nor statically shallower, than any other.
Modify 7.6.1(3/2):
After execution of a construct or entity is complete, it is left, meaning that execution continues with the next action, as defined for the execution that is taking place. Leaving an execution happens immediately after its completion, except in the case of {the execution of} a master {construct}: [the execution of] a body other than a package_body; [the execution of] a statement; or [the evaluation of] an expression, function_call, or range that is not part of an enclosing expression, function_call, range, or simple_statement other than a simple_return_statement. {The term master by itself refers to the execution of a master construct.} A master is finalized after it is complete, and before it is left.
Revise the existing (from AI12-0330-1) glossary entry:
Master: A master is the execution of a master construct. Each object and task is associated with a master. when a master is left, associated objects are finalized and associated tasks are awaited.
Add a glossary entry:
Master construct: A master construct is one of certain executable constructs. Execution of a master construct is a master, with which objects and tasks are associated for the purposes of finalization and waiting.
!discussion
(1) AARM 3.10.2(18.a) admits that talking about masters in a Legality Rule is bogus; by introducing the term "master constructs" we eliminate this problem.
We do not expect this rewording to require any change to implementations. Existing ACATS tests and implementations do make static accessibility checks in generic units; we're just making the wording in the Standard match the common sense definition of static nesting -- and avoid talking about a compile-time interpretation of an execution.
(2) 3.10.2(19/3) says that the statically deeper relationship does not apply to generic formal types, while 3.10.2(20) says that a generic package body is assumed instantiated at the level it is declared. The reason for the difference is that a generic unit can be instantiated at the same level or a deeper level; it cannot be instantiated at an outer level (as it is not visible). Thus, we can assume that the level is at least that of the declaration and make appropriate static checks in that case. This is essentially an "assume-the-best" rule with dynamic checks (and rechecking in the specification of the instance) used when the best isn't true.
However, the actual for a generic formal type parameter can be of any level up to the level of the instance. In particular, a type declared at library-level can be passed to an instance at a very deep level. Thus, there is no useful assumption about the level of a formal type that can be made, and therefore we say that no static checks can be made for it. Dynamic checks (and rechecking in the specification of the instance) are used in all cases to avoid problems.
Types declared in a generic formal package act much like those which are directly generic formal types. In particular, an instance declared at an outer level can be the actual for a formal package; and thus types declared in formal packages should be treated in the same way as generic formal types.
!example
The following example is a distillation of an AdaCore customer problem report.
procedure Aaa is type Root is tagged null record; type Ref is access Root'Class;
generic package G1 is type Ext is new Root with null record; end G1;
generic with package I1 is new G1 (<>); procedure G2;
procedure G2 is Ptr : Ref := new I1.Ext; -- (1) begin null; end G2;
-- package My_I1 is new G1; -- procedure My_I2 is new G2 (My_I1); begin -- My_I2; null; end Aaa;
The Ada 2012 rules make the allocator at (1) illegal, by 4.8(5.2/3). With the wording change proposed by this AI, (1) becomes legal as the "statically deeper" relationship does not apply. A dynamic check is still requires at one, in case the instance of G2 is nested more than type Ref.
!ASIS
No ASIS effect.
!ACATS test
No (new) tests should be needed for question (1). For question (2), a C-Test like the example is needed to check that types in formal packages are treated properly.
!appendix

****************************************************************

Questions? Ask the ACAA Technical Agent