CVS difference for ai12s/ai12-0399-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file 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