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

** TBD.

A Default_Initial_Condition is evaluated when a default-initialized object is created. Aspect Preelaborable_Initialization (P_I) does not take into account any such evaluation when it determines whether a component has P_I. That means that such an evaluation could execute operations not otherwise allowed during the elaboration of a preelaborated package. This seems to circumvent the purpose of aspect P_I. Can this be fixed? (Hope so. :-)

*** TBD.

** Temporary summary of discussion to date **

This topic was raised by Steve Baird in his review. This was the last review processed by the editor. We discussed this briefly but were unable to decide on an appropriate fix before the agenda deadline.

Steve noted that we had discussed this briefly in e-mail when Default_Initial_Condition was introduced. Completely disallowing assertion aspects on types that have preelaborable initialization is way too fierce. For instance, the containers have P_I and also have a default initial condition.

Randy noted that 7.3.2(11/4) says that a Type_Invariant is checked when an object is initialized by default. That means the same issue arises for Type_Invariant. Similarly, an initialization of a type with a Default_Value aspect could require a predicate check when the value is converted to the appropriate subtype. Finally, an initialization of a component could require a predicate check when the value is converted to the appropriate subtype.

Arguably, 10.2.1(11.3/2) covers the latter case, but only when the predicate is enabled. None of the other cases are covered by the rules in 10.2.1.

Tucker suggested that one could consider the checks to occur after the preelaborated initialization of the packages. The C.4 rules that require no code to be executed disallow private types and dynamically constrained subtypes, so type invariants and (interesting) predicates are not relevant there.

Randy, however, points out that such a model would still allow executing operations not otherwise allowed during the elaboration of a preelaborated package. That would seem to threaten the invariants that preelaboration is good for, including the reduction of use-before-elaboration checks.

The agenda deadline was reached before there was more discussion on this topic.

No ASIS effect.

*** TBD (it will depend on the choice of rules).

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