CVS difference for ai12s/ai12-0399-1.txt
--- ai12s/ai12-0399-1.txt 2020/10/22 23:59:00 1.2
+++ ai12s/ai12-0399-1.txt 2020/12/17 04:14:26 1.3
@@ -1,13 +1,4 @@
-!standard 9.5(53/5) 20-10-21 AI12-0399-1/02
-!standard 10.2.1(4.1/2)
-!standard 10.2.1(4.2/2)
-!standard 10.2.1(11.1/2)
-!standard 10.2.1(11.2/2)
-!standard 10.2.1(11.6/2)
-!standard 10.2.1(11.7/2)
-!standard 10.2.1(11.8/2)
-!standard 13.1(11/3)
-!standard J.15.14(0)
+!standard 9.5(53/5) 20-12-14 AI12-0399-1/03
!class Amendment 20-10-15
!status Amendment 1-2012 20-10-21
!status ARG Approved 13-1-0 20-10-21
@@ -19,80 +10,41 @@
!summary
-We define Preelaborable_Initialization to be an aspect, and allow for
-the situation where the full view is defined by the language or inheritance
-to be True, while the partial view is False. We use this for Nonblocking
-as well, as it has a similar problem, where the full view might be defined
-by the language to be Nonblocking, even if the partial view defaults to
-False.
+All Preelaborable_Initialization pragmas in the language-defined units
+are replaced by aspects.
+We allow for the situation for aspect Nonblocking where the full view is
+defined by the language or inheritance to be True, while the partial view
+is False.
+
!problem
-Preelaborable_Initialization is one of the few remaining pragmas that
-cannot be specified using an aspect specification. The reason for this
-is a technicality (see AI05-0229-1):
-
- ===pragma Preelaborable_Initialization (referred to as P_I below)
-
- [Editor's Note: This pragma does not work well as a type-related
- aspect, as it is view dependent. In particular, even if a partial view
- does not have the P_I property, the full view might have the P_I
- property. That is contrary to 13.1(11/2) for operational and
- representation aspects. (In the absence of a change to 13.1(11/2),
- we'd have a compatibility problem.) ...]
+(1) AI12-0409-1 defines a Preelaborable_Initialization aspect, and
+makes the Preelaborable_Initialization pragma obsolescent. However, the
+language-defined units still use the pragma. We generally do not use
+obsolescent features in the language-defined units.
---
-This seems like it could be fixed, and it is a bit of an anomaly. I
-believe the goal was that it was OK if the partial view did not have the
-aspect visibly True, since you might change the implementation at some
-point to not have preelaborable initialization. On the other hand, for
-other aspects we are forcing you to reveal the full view's aspect in the
-partial view. Nonblocking is currently such an aspect, though we believe
-this should probably also be changed. There are two conceivable
-approaches, but only the second really works for
-Preelaborable_Initialization:
-
- 1) Force the partial view to match the full view, and say that it has
- Preelaborable_Initialization, even if at some later point you fear the
- implementation might no longer be able to meet that requirement -- alas
- this doesn't really work as it would require pragma
- Preelaborable_Initialization for all private types that turn out to
- have a full type with preelaborable initialization -- this would be
- quite incompatible with the current language;
-
- 2) Allow the partial view and the full view to have different values
- for certain Boolean-valued aspects, but probably limited to False for
- the partial view and True for the full view. We already have a rule
- analogous to this on inheritance of Boolean aspects, in RM
- 13.1.1(18.1/5):
-
- If an aspect of a derived type (or its first subtype) is inherited
- from an ancestor (sub)type and has the boolean value True, the
- inherited value shall not be overridden to have the value False for
- the derived type (or its first subtype), unless otherwise specified
- in this International Standard. If an aspect of a nonfirst subtype is
- inherited from the subtype in the subtype_indication that defines it,
- and has the value True, the inherited value shall not be overridden
- to have the value False for the nonfirst subtype, unless otherwise
- specified in this International Standard.
-
-We *do* allow aspects to be completely unspecified on a partial view,
-while being specified on the full view (RM 13.1.1(35/3)). So this could
-be seen as a variant of that for Boolean aspects for which "False" is
-the default value if not specified.
+(2) AI12-0409-1 allows aspects to support the situation where the full view
+is defined by the language or inheritance to be True, while the partial view
+is False. It makes sense to allow this for Nonblocking, as it should allow
+the case where the full view might be defined by the language to be
+Nonblocking, even if the partial view defaults to False.
!proposal
-Modify the general rule about partial view and full view having the same
-value for all aspects, to allow an exception for certain boolean-valued
-aspects, where the partial view may be False while the full view is
-True. We would use this at least for Preelaborable_Initialization where
-we would allow the full type to be "better behaved" than the partial
-view. We also apply this to Nonblocking (though it is subtype-specific),
-for largely the same reason, given that certain subtypes are by
-definition Nonblocking, and having a requirement to specify Nonblocking
-=> True for the partial view of such a subtype is not upward compatible.
+(1) All Preelaborable_Initialization pragmas in the language-defined units
+are replaced by aspects. Note that AI12-0409-1 already replaced a few this
+way.
+
+(2) AI12-0409-1 modifies the general rule about partial view and full view
+having the same value for all aspects, to allow an exception for certain
+boolean-valued aspects, where the partial view may be False while the full
+view is True. We apply this to Nonblocking (though it is subtype-specific),
+given that certain subtypes are by definition Nonblocking, and having a
+requirement to specify Nonblocking => True for the partial view of such a
+subtype is not upward compatible.
!wording
@@ -118,82 +70,7 @@
Nonblocking aspect of the full view is inherited, it shall have the
same value as that of the partial view{, or have the value True}.
-Move 10.2.1(4.1/2, 4.2/2) defining the pragma
-Preelaborable_Initialization to Annex J, as section J.15.14.
-
-Modify 10.2.1(11.1/2):
-
- The following rules specify which entities have preelaborable
- initialization {, namely that the Preelaborable_Initialization aspect
- of the entity is True}.
-
-Modify 10.2.1(11.2/3):
-
- The partial view of a private type or private extension, a protected
- type without entry_declarations, a generic formal private type, or a
- generic formal derived type, has preelaborable initialization if and
- only if the [pragma] Preelaborable_Initialization {aspect} has been
- [applied to]{specified True for} them. [Redundant: A protected type
- with entry_declarations or a task type never has preelaborable
- initialization.] {The Preelaborable_Initialization aspect of a partial
- view of a type may be specified as False, even if the full view of the
- type has preelaborable initialization. Similarly, a generic formal
- type need hot be specified to have preelaborable initialization, even
- if the actual type in an instance has preelaborable initialization.}
-
-Move 10.2.1(11.6/2) to Annex J, with modifications (see Annex J below).
-
-Modify 10.2.1(11.7/3):
- {The Preelaborable_Initialization aspect shall be directly specified
- only for a composite type declared within the visible part of a
- package or a generic package.} [If the pragma appears in the first
- list of basic_declarative_items of a package_specification, then the
- direct_name shall denote the first subtype of a composite type, and
- the type shall be declared immediately within the same package as the
- pragma.] If the [pragma is applied to]{Preelaborable_Initialization
- aspect is specified True for} a private type or a private
- extension, the full view of the type shall have preelaborable
- initialization. If the [pragma is applied to]{aspect is specified True
- for} a protected type, the protected type shall not have entries, and
- each component of the protected type shall have preelaborable
- initialization. For any other composite type, the [type shall have
- preelaborable initialization]{aspect shall be specified only if it is
- confirming}. In addition to the places where Legality Rules normally
- apply (see 12.3), these rules apply also in the private part of an
- instance of a generic unit.
-
-Modify 10.2.1(11.c/3):
-
- AARM Reason: {AI05-0028-1} The reason why we need [the pragma]{to
- specify the aspect} for private types, private extensions, and
- protected types is fairly clear: the properties of the full view
- determine whether the type has preelaborable initialization or not;
- in order to preserve privacy we need a way to express on the partial
- view that the full view is well-behaved. The reason why we need [the
- pragma]{to specify the aspect} for other composite types is more
- subtle: a nonnull override for Initialize might occur in the private
- part, even for a nonprivate type; in order to preserve privacy, we
- need a way to express on a type declared in a visible part that the
- private part does not contain any nasty override of Initialize.
-
-Modify 10.2.1(11.8/2):
-
- If the [pragma appears]{aspect is directly specified on a type
- declared} in a generic_formal_part, then [the direct_name shall
- denote]{the type shall be} a generic formal private type or a generic
- formal derived type declared in the same generic_formal_part as the
- pragma. In a generic_instantiation the corresponding actual type shall
- have preelaborable initialization.
-
-Modify 10.2.1(11.d/2):
-
- AARM Ramification: Not only do protected types with
- entry_declarations and task types not have preelaborable
- initialization, but they cannot have [pragma]{the aspect}
- Preelaborable_Initialization [applied to]{specified True for}
- them.
-
Modify 11.4.1(2/5):
...
@@ -207,18 +84,6 @@
[pragma]{with} Preelaborable_Initialization[(Exception_Occurrence)];
...
-Modify 13.1(11/3) -- as defined in AI12-0396-1:
-
- If a type-related aspect is defined for the partial view of a type,
- then it has the same definition for the full view of the type{, except
- for certain Boolean-valued operational aspects where the language
- specifies that the partial view can have the value False even when the
- full view has the value True}. ...
-
- {AARM Discussion: This applies to aspect
- Preelaborable_Initialization. Nonblocking has a similar rule,
- though it is a subtype-specific aspect.}
-
Modify 13.11(6/2):
type Root_Storage_Pool is
@@ -260,65 +125,10 @@
Modify C.7.1(2/5)
Modify G.1.1(4/2)
-Add the following section to Annex J:
-
- J.15.14 Pragma Preelaborable_Initialization:
-
- Syntax
-
- The form of a pragma Preelaborable_Initialization is as follows:
-
- pragma Preelaborable_Initialization(direct_name);
-
- Legality Rules
-
- A pragma Preelaborable_Initialization specifies that the
- Preelaborable_Initialization aspect (see 10.2.1) for a composite type
- is True. This pragma shall appear in the visible part of a package or
- generic package.
-
- If the pragma appears in the first list of basic_declarative_items of
- a package_specification, then the direct_name shall denote the first
- subtype of a composite type, and the type shall be declared
- immediately within the same package as the pragma. The composite type
- shall be one for which the Preelaborable_Initialization aspect can be
- directly specified as True. In addition to the places where Legality
- Rules normally apply (see 12.3), these rules apply also in the private
- part of an instance of a generic unit.
-
- If the pragma appears in a generic_formal_part, then the direct_name
- shall denote a type declared in the same generic_formal_part as the
- pragma, and be one for which the Preelaborable_Initialization aspect
- can be directly specified as True.
-
!discussion
-It is an anomaly that Preelaborable_Initialization is the only
-"characteristic" of a type that is not considered an aspect. The reason
-we had deferred making this an aspect had to do with the now-altered
-rule that all views of a type would have the same value for all aspects.
-We now limit that rule to representation aspects. For operational
-aspects, we recognize that there are reasons why the partial view might
-want to be different, especially if the full view has a language-defined
-value for the aspect, which is true for both
-Preelaborable_Initializaation for certain simple types and for
-Nonblocking for base subtypes of elementary types. It is awkward for
-the partial view to be required to reveal this property of the full
-type, and it would be incompatible to do so for
-Preelaborable_Initialization, and for Nonblocking, as suddenly various
-private types would be required to have these aspects explicitly
-specified.
-
-Therefore, we recognize these special cases, where the default value of
-False generally imposes no special requirement, while the value of True
-does impose requirements on the type and some of its operations. For such
-cases we permit the value for the full type to be True, even if the partial
-view makes no such "promise" by having the value False for the aspect.
+(See !proposal.)
-We move the pragma to the Obsolescent Annex (Annex J), to be consistent
-with our handling of other similar pragmas.
-
-
!ASIS
[Not sure. It seems like some new capabilities might be needed,
@@ -600,6 +410,12 @@
Aspect Nonblocking shall be directly specified for the first subtype of the
full view of a type that has a partial view only if it has the same value
as the Nonblocking aspect of the partial view or if it is specified True.
+
+****************************************************************
+
+Editor's note: During meeting #62H, we voted to move most of this AI to
+AI12-0409-1 (and change that AI to a binding interpretation). Parts that don't
+need to apply to Ada 2012 are left here.
****************************************************************
Questions? Ask the ACAA Technical Agent