CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/03/31 06:48:05 1.10
+++ ai05s/ai05-0229-1.txt 2011/04/01 01:35:18 1.11
@@ -1,4 +1,4 @@
-!standard 13.2(5) 11-03-30 AI05-0229-1/06
+!standard 13.2(5) 11-03-31 AI05-0229-1/07
!standard 13.11.3(5)
!standard B.3.3(4)
!standard E.4.1(8)
@@ -28,10 +28,9 @@
!wording
-Replace the penultimate paragraph of the Static Semantics
-in AI05-0183-1:
+Replace the fourth paragraph from the end of the Static Semantics
+in AI05-0183-1/09 (13.3.1(30/3) in draft 11.5):
-
All specifiable operational and representation attributes may be
specified with an aspect_specification instead of an
attribute_definition_clause (see 13.3).
@@ -449,52 +448,117 @@
Other pragmas:
-** Unchanged - TBD ** - Assigned to Steve
===pragma Preelaborable_Initialization (the pragma is to be obsolescent)
+
+Delete 10.2.1(4.1/2-4.2/2) [Now in Annex J.]
-Replace 10.2.1(11.6/2):
+In 10.2.1(10.1/3), replace
+ ..., unless pragma Preelaborable_Initialization has been applied
+ to the formal type;
+with
+ ..., unless the Preelaborable_Initialization aspect is True for
+ the formal type.
+
+Replace 10.2.1(11.1-11.8/2) with: [This includes corrections from AI05-0028-1
+and AI05-0221-1.]
+
+The following rules specify which entities are said to be *eligible for
+preelaborable initialization*:
+
+ * 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, is eligible for preelaborable initialization if
+ and only if the Preelaborable_Initialization aspect is True for them. A
+ protected type with entry_declarations or a task type is never eligible
+ for preelaborable initialization.
+
+ [Note: "Redundant" square brackets in preceding paragraph removed
+ deliberately.]
+
+ * A component (including a discriminant) of a record or protected type
+ is eligible for 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 is
+ eligible for preelaborable initialization.
+
+ * A derived type is eligible for preelaborable initialization if its
+ parent type is eligible for preelaborable initialization and if the
+ non-inherited components are all eligible for preelaborable initialization.
+ However, a user-defined controlled type with an overriding Initialize
+ procedure that is not a null procedure is not eligible for
+ preelaborable initialization.
+
+ * A view of a type is eligible for preelaborable initialization if it is an
+ elementary type, an array type whose component type is eligible for
+ preelaborable initialization, a record type whose components all are
+ eligible for preelaborable initialization, or an interface type.
+
+For any type, the following language-defined type-related operational
+aspect is defined:
+ Preelaborable_Initialization
+ The type of aspect Preelaborable_Initialization is Boolean. If aspect
+ Preelaborable_Initialization is True for a type, the type is said to
+ have *preelaborable initialization*; conversely, if the aspect is
+ False, the type does not have preelaborable initialization.
+
+[Editor's Note: This aspect has to be operational so we can specify it on
+partial views; that's not allowed for representation aspects.]
+
+ For a composite type_declaration other than an incomplete_type_declaration
+ and for a composite formal_type_declaration, this aspect may be specified.
+ If not directly specified for a given type (including the case of derived
+ type), the aspect is True if and only if the type is eligible for
+ preelaborable initialization. If directly specified, the aspect_definition
+ shall be a static expression. [redundant: The aspect is never inherited.]
+
+ If the aspect Preelaborable_Initialization is True for a type,
+ * the type shall be eligible for preelaborable initialization; and
+ * the full view of the type (if any) shall be eligible for preelaborable
+ initialization.
+
+ If the aspect Preelaborable_Initialization is True for a generic
+ formal type, then the corresponding actual type in an generic_instantiation
+ shall have preelaborable initialization.
+
+ 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 reason: The reason why the aspect may be specified 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 for supporting
+ this for other composite types is more subtle: a non-null 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.
+
+ AARM ramification: A value of True may not be specified for the
+ Preelaborable_Initialization aspect of a protected types with one
+ or more entry_declarations or of a task type.
+
+[Editor's note: The Static Semantics and Legality Rules are all mixed together
+here. We typically don't do that, but since we already did that in the past, it
+is left that way here.]
+
+In 10.2.1(15.a/3). replace
+ "; the type still could have a pragma Preelaborable_Initialization given"
+with
+ "; the Preelaborable_Initialization aspect of the type could still be True"
+
+
+[Editor's Note: This aspect can be specified on generic formal types. Thus
+the AI05-0183-1 statement that there are none is a lie. Gotta fix it.]
+
+Replace the penultimate paragraph in Static
+Semantics for AI05-0183-1/09 [13.3.1(32/3) in draft 11.5]:
+
+There are no language-defined aspects that may be specified on a renaming_declaration
+and only Preelaboration_Initialization (see 10.2.1) can be specified on a
+formal_type_declaration.
-A pragma Preelaborable_Initialization sets the Preelaborable_Initialization
-operational aspect of the type denoted by direct_name to the value True; the
-aspect may also be set by the aspect_specification of the declaration of a type.
-The pragma shall only appear in the visible part of a package or generic
-package. The aspect Preelaborable_Initialization shall only be specified for a
-composite type declared in the visible part of a package or generic package.
-
-[Note: This has to be an operational aspect, in order to be allowed to appear on
-a partial view.]
-
-Replace the middle three sentences of 10.2.1(11.7/3):
-
-If the aspect is True for a private type or a private extension, the
-full view of the type shall have preelaborable initialization. If the aspect has
-the value 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 True for any other composite type,
-the type shall have preelaborable initialization.
-
-Replace 10.2.1(11.8/3):
-
-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
-actual type corresponding to a generic formal type with the
-Preelaborable_Initialization aspect having the value True shall have
-preelaborable initialization.
-
-AARM Ramification: This aspect may be specified on generic formal types that
-might be composite.
-
-[Editor's Note: Better redo the AARM note in AI05-0183-1 to mention this!]
-
-[Editor: It might have been better to recast the entire
-"preelaborable_initialization" (PI) property as an operational aspect of the
-type. That would require a lot more rewording, as types that "have" PI would
-instead have the PI aspect with a value of True; types that have PI specified
-would have to be completed with full types that also have PI with a value of
-True, and so on. That seems like it would involve a lot of opportunities for
-errors, so I went with the minimal change (even though it doesn't make much
-sense logically).]
===pragma Interrupt_Handler and Attach_Handler (the pragma is to be obsolescent)
@@ -1207,6 +1271,38 @@
have the value of the given expression [Redundant: as evaluated at object creation
time].
+J.15.12 pragma Preelaborable_Initialization
+
+ Syntax
+
+ The form of a pragma Preelaborable_Initialization is as follows:
+ pragma Preelaborable_Initialization (direct_name);
+
+ Static Semantics
+ A pragma Preelaborable_Initialization specifies the
+ Preelaborable_Initialization aspect (see 10.2.1) of the
+ type denoted by its argument is True.
+
+[Editor's note: This is not a representation pragma since this is an operational
+aspect. Representation pragmas cannot be specified on partial views by 13.1(9).]
+
+ Legality Rules
+ A Preelaborable_Initialization 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 such that the Preelaborable_Initialization
+ aspect of the type may be specified to be True, and the type shall be declared
+ immediately within the same package as the pragma.
+
+ If the pragma appears in a generic_formal_part, then the direct_name shall
+ denote a composite generic formal type declared in the same
+ generic_formal_part as the pragma such that the Preelaborable_Initialization
+ aspect of the type may be specified to be 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.
*** Additional obsolescent pragmas here ***
Questions? Ask the ACAA Technical Agent