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

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0409-1.txt

--- ai12s/ai12-0409-1.txt	2020/12/11 22:22:26	1.3
+++ ai12s/ai12-0409-1.txt	2020/12/17 04:12:46	1.4
@@ -1,6 +1,12 @@
-!standard 10.2.1(11.6/2)                                20-12-11  AI12-0409-1/02
-!standard 10.2.1(11.7/3)
+!standard 10.2.1(4.1/2)                                20-12-15  AI12-0409-1/03
+!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 A.18.19(5/5)
 !standard A.18.20(5/5)
 !standard A.18.21(5/5)
@@ -9,24 +15,85 @@
 !standard A.18.24(5/5)
 !standard A.18.25(5/5)
 !standard A.18.32(6/5)
-!class Amendment 20-12-03
+!class Binding Interpretation 20-12-09
 !status Amendment 1-2012 20-12-11
 !status ARG Approved 11-0-3  20-12-09
 !status work item 20-12-03
 !status received 20-11-27
-!priority Low
+!priority Medium
 !difficulty Easy
-!subject Preelaborable_Initialization and bounded containers
+!qualifier Error
+!subject Preelaborable_Initialization aspect and bounded containers
 !summary
 
-We define a Preelaborable_Initialization attribute, which is defined only for 
+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 also define a Preelaborable_Initialization attribute, which is defined only for 
 composite types defined in the visible part of a package or a generic package,
 and allow the aspect definition for a nonformal type declared within a generic
 package to depend on the value of such an attribute.
 
 !problem
+
+[A] 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.) ...]
+
+---
 
-Is it intended that a bounded container has Preelaborable_Initialization even 
+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.
+
+===
+
+[B] Is it intended that a bounded container has Preelaborable_Initialization even 
 if the actual Element_Type does not have Preelaborable_Initialization? That
 seems to make it impossible to store the elements directly in the container,
 and seems to require some sort of dynamic memory allocation (contrary to the
@@ -34,15 +101,14 @@
 
 !proposal
 
-[Editor's note: Arguably, this should be a Binding Interpretation, since the
-existing definition of the Bounded containers doesn't make any sense. But for
-that to work, we'd have to reclassify AI12-0399-1 as a Binding Interpretation
-as well (we can't modify the definition of an aspect that doesn't exist ;-).
-I'd suggest we split 399 in that case, as the changes to change pragmas to
-aspects should be part of Ada 202x presentation improvements and not some
-retroactive change. ** I need to do this **]
+[A] 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.
 
-A bounded container should have Preelaborable_Initialization only if the 
+[B] A bounded container should have Preelaborable_Initialization only if the 
 actual Element_Type (and Key_Type for Maps) has Preelaborable_Initialization.
 We introduce a Preelaborable_Initialization attribute for formal composite 
 types, and allow it to be used in the definition for the 
@@ -52,9 +118,33 @@
 !wording
 
 [Author's note: This is defined as modifications to the wording introduced by AI12-0399-1.]
+
+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):
 
-In place of 10.2.1(11.6/2), which was moved to Annex J, add the following:
+  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.}
 
+In place of 10.2.1(11.6/2), which is moved to Annex J with modifications
+(see below), add the following:
+
   The following attribute is defined for a nonformal composite subtype S
   declared within the visible part of a package or a generic package, or
   a generic formal private subtype or formal derived subtype.
@@ -74,12 +164,15 @@
 
 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 Preelaborable_Initialization
-  aspect is specified True for a private type or a private extension,
+  [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 aspect is specified True for a protected type, the protected type
+  the [pragma is applied to]{aspect is specified True
+  for} for a protected type, the protected type
   shall not have entries, and each component of the protected type shall
   have preelaborable initialization. {If the aspect is specified True
   for a generic formal type, then in a generic_instantiation the
@@ -88,20 +181,55 @@
   Preelaborable_Initialization attribute references, then the full view
   of the type shall have preelaborable initialization presuming the
   types mentioned in the conjunction all have preelaborable
-  initialization.} For any other composite type, the aspect shall be
-  specified statically True or False only if it is confirming. In
+  initialization.} For any other composite type, the [type shall have
+  preelaborable initialization]{aspect shall be 
+  specified statically True or False 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.
+
 Delete 10.2.1(11.8/2), which is now covered above.
 For reference, this paragraph was:
 
-  If the aspect is directly specified on a type declared in a
-  generic_formal_part, then 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.
+  If the pragma appears in a generic_formal_part, then the direct_name shall
+  denote 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 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.}
 
 Add after A.18.19(5/5):
 
@@ -163,9 +291,65 @@
       Preelaborable_Initialization =>
         Element_Type'Preelaborable_Initialization
 
+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
+
+(1) 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.
 
-We debated various ways to address this issue. Although we have abandoned 
+We move the pragma to the Obsolescent Annex (Annex J), to be consistent
+with our handling of other similar pragmas.
+
+(2) We debated various ways to address this issue. Although we have abandoned 
 the use of attributes for Nonblocking and Global, we felt that for this 
 particular aspect, allowing the use of an attribute was the simplest 
 solution. We considered defining some additional aspect, or making some
@@ -700,7 +884,6 @@
 
 ---
 
-
 !wording
 > [Author's note: This is defined as modifications to the wording 
 > introduced by AI12-0399-1.]
@@ -798,5 +981,176 @@
 generic bodies?? (In case you missed what I'm driving at, you cannot know at 
 generic unit compile-time what the value for the parent type is. So how do you 
 know if the rule applies?)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, December 8, 2020  9:22 PM
+
+I have sent Randy some responses to these comments privately.  I'll discuss 
+them during the meeting.  But in the mean time, it seemed like a lot of the 
+difficulty in understanding this AI was the mixture of wording coming from 
+the RM draft 27, AI12-0399-1, and this AI.  So I have combined all of the 
+wording, deleted the parts that are going to be removed, shown the new parts
+in {...}, and provided it below.  Hopefully this can be a better place to 
+start our discussions on this AI.  I know Randy still has comments that apply
+to this combined wording, but hopefully it will be easier for everyone if we 
+aren't trying to on-the-fly patch the wording together in our heads.
+
+> On Dec 3, 2020, at 10:39 PM, Randy Brukardt <Randy@RRSOFTWARE.COM> wrote:
+> 
+> I had a number of comments on the draft of AI12-0409-1 that will be on the
+> agenda; since Tucker does not plan to address any of them before the agenda
+> is posted I'm putting them here for the record (so we can discuss them at
+> the meeting or here). The full AI will go up with the agenda tonight.
+> 
+> ---
+> 
+> ...
+
+======== combined wording from RM, AI12-0399-1, and AI12-0409-1 =========
+
+Here is a complete rewrite of the part of 10.2.1 that relates to preelaborable 
+initialization, with the obsolete parts marked [...] in the AIs eliminated completely:
+
+  An elaborable construct is preelaborable unless its elaboration
+  performs any of the following actions:
+
+  ...
+
+  * The creation of an object [Redundant: (including a component)] that
+    is initialized by default, if its type does not have preelaborable
+    initialization. Similarly, the evaluation of an extension_aggregate
+    with an ancestor subtype_mark denoting a subtype of such a type.
+
+  * The elaboration of any elaborable construct that is not
+    preelaborable.
+
+  A generic declaration is preelaborable unless every instance would
+  perform one of the above actions.
+
+  A generic body is preelaborable only if elaboration of a corresponding
+  instance body would not perform any such actions, presuming that:
+
+  * the actual for each discriminated formal derived type, formal
+    private type, or formal private extension declared within the formal
+    part of the generic unit is a type that does not have preelaborable
+    initialization, unless {the Preelaborable_Initialization aspect is
+    specified True for} the formal type;
+
+  * the actual for each formal type is nonstatic;
+
+  * the actual for each formal object is nonstatic; and
+
+  * the actual for each formal subprogram is a user-defined subprogram. 
+ 
+  A pragma Preelaborate (or pragma Pure  see below) is used to specify
+  that a library unit is preelaborated, namely that the Preelaborate
+  aspect of the library unit is True; all compilation units of the
+  library unit are preelaborated. The declaration and body of a
+  preelaborated library unit, and all subunits that are elaborated as
+  part of elaborating the library unit, shall be preelaborable. All
+  compilation units of a preelaborated library unit shall depend
+  semantically only on declared pure or preelaborated library_items. In
+  addition to the places where Legality Rules normally apply (see 12.3),
+  these rules also apply in the private part of an instance of a generic
+  unit. [Redundant: If a library unit is preelaborated, then its
+  declaration, if any, and body, if any, are elaborated prior to all
+  nonpreelaborated library_items of the partition.]
+
+  Subunits of a preelaborated subprogram unit do not need to be
+  preelaborable. This is needed in order to be consistent with units
+  nested in a subprogram body, which do not need to be preelaborable
+  even if the subprogram is preelaborated. However, such subunits cannot
+  depend semantically on nonpreelaborated units, which is also
+  consistent with nested units.
+
+  The following rules specify which entities have preelaborable
+  initialization{, namely that the Preelaborable_Initialization aspect
+  of the entity is True}:
+
+  * 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 Preelaborable_Initialization {aspect} has been
+    {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.}
+
+  * A component (including a discriminant) of a record or protected type
+    has preelaborable initialization if its declaration includes a
+    default_expression whose execution does not perform any actions
+    prohibited in preelaborable constructs as described above, or if its
+    declaration does not include a default expression and its type has
+    preelaborable initialization.
+
+  * A derived type has preelaborable initialization if its parent type
+    has preelaborable initialization and if the noninherited components
+    all have preelaborable initialization. However, a controlled type with
+    an Initialize procedure that is not a null procedure does not have
+    preelaborable initialization.
+
+  * A view of a type has preelaborable initialization if it is an
+    elementary type, an array type whose component type has preelaborable
+    initialization, a record type whose components all have preelaborable
+    initialization, or an interface type.
+  
+  {The following attribute is defined for a nonformal composite subtype S
+  declared within the visible part of a package or a generic package, or
+  a generic formal private subtype or formal derived subtype.
+
+  S'Preelaborable_Initialization
+  
+    This attribute is of Boolean type, and its value reflects whether
+    the type of S has preelaborable initialization. The value of this
+    attribute, the type-related Preelaborable_Initialization aspect, may
+    be specified for any type for which the attribute is defined. The
+    value shall be specified by a static expression, unless the type is
+    not a formal type but is nevertheless declared within a generic
+    package.  In this latter case, the value may also be specified by
+    references to the Preelaborable_Initialization attribute of one or
+    more formal types visible at the point of the declaration of the
+    composite type, conjoined with "and".}
+
+      AARM Reason: {AI05-0028-1} The reason why we need {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 {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.
+  
+  If the {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 {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. {If the aspect is specified True for a generic formal
+  type, then in a generic_instantiation the corresponding actual type
+  shall have preelaborable initialization. If the aspect is specified to
+  be the conjunction of one or more Preelaborable_Initialization
+  attribute references, then the full view of the type shall have
+  preelaborable initialization presuming the types mentioned in the
+  conjunction all have preelaborable initialization.} For any other
+  composite type, the {aspect shall be specified statically True or False
+  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.
+  
+    AARM Ramification: Not only do protected types with
+    entry_declarations and task types not have preelaborable
+    initialization, but they cannot have {the aspect}
+    Preelaborable_Initialization {specified True for}
+    them.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent