CVS difference for ai05s/ai05-0028-1.txt

--- ai05s/ai05-0028-1.txt	2007/03/27 22:52:34	1.4
+++ ai05s/ai05-0028-1.txt	2007/04/05 01:49:14	1.5
@@ -1,4 +1,4 @@
-!standard 10.2.1(9/2)                                     07-01-12    AI05-0028-1/03
+!standard 10.2.1(9/2)                                     07-04-04    AI05-0028-1/04
 !standard 10.2.1(10.1/2)
 !standard 10.2.1(11.4/2)
 !standard 10.2.1(11.8/2)
@@ -11,7 +11,11 @@
 !subject Problems with preelaboration
 !summary 
 
-TBD.
+The rules related to preelaborable initialization and to pragma
+Preelaborable_Initialization are fixed to eliminate a number of inconsistencies:
+in some cases they were too strict, disallowing perfectly legitimate constructs,
+and in other cases they were too lax, allowing constructs that could lead to
+problems.
 
 !question
 
@@ -92,17 +96,84 @@
 
 !wording
 
-TBD.
+For questions 1 and 2, change 10.2.1(10.1/2) as follows:
 
-For question 7, replace the first sentence of 10.2.1(9/2) with:
+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 pragma
+Preelaborable_Initialization has been applied to the formal type};
+
+For question 4, change the second sentence of 10.2.1(11.4/2) as follows:
+
+However, a [user-defined] controlled type with an [overriding] Initialize procedure
+{that is not a null procedure} does not have preelaborable initialization.
+
+For question 5, change 10.2.1(11.7/1) as follows:
+
+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 [private type, private extension, or protected type] {composite type} that is
+not an interface type{, a task type, or a protected_type with} [and is without]
+entry_declarations, and the type shall be declared immediately within the same
+package as the pragma. If the pragma is applied to a private type or a private
+extension, the full view of the type shall have preelaborable initialization. If
+the pragma is applied to [a protected type, each component of the protected] {any
+other composite type, the} type shall have preelaborable initialization. In addition
+to the places where Legality Rules normally apply, these rules apply also in the
+private part of an instance of a generic unit.
+
+AARM Note: The reason why we need the pragma 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 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.
 
-   The creation of an object that is initialized by default of a type
-   that does not have preelaborable initialization.
+For question 7, replace the first sentence of 10.2.1(9/2) with:
 
+The creation of an object [(including a component)] {that is initialized by default}
+of a type that does not have preelaborable initialization.
 
 !discussion
 
-TBD.
+For question 1, it is clear that the purpose of allowing pragma
+Preelaborable_Initialization for a formal type was to ensure that the actual type
+would have preelaborable initialization, so it is silly for the assume-the-worst rules
+to not take the pragma into account. Note incidentally that the assume-the-worst rules
+only apply to generic bodies, not to generic specifications: the specification will be
+rechecked when the generic is instantiated, but we won't have a second chance for the
+body.
+
+For question 2, we must be cautious to avoid creating incompatibilities. Disallowing any
+object of a formal derived type would be a disaster. We want to limit ourselves to the
+case where the formal type is discriminated because that the only case where the actual
+and formal types may have different defaults. Incompatibilities should be rare, and
+can easily be fixed with pragma Preelaborable_Initialization.
+
+For question 3, the petitioner seems confused, as the example is illegal by 10.2.1(10.2/2).
+
+For question 4, it is clear that the case of a null Initialize procedure was overlooked.
+It seems useful to be able to "regain" preelaborable initialization by overriding
+Initialize with a null procedure. Furthermore, because Ada.Finalization.Initialize is a
+null procedure, the wording is simplified a bit by the new rule.
+
+For question 5, we need to be able to apply pragma Preelaborable_Initialization to
+any type that may have a controlled part, because the Initialize procedure for that
+part may be overridden in a private part. This means that the pragma now applies to
+practically any composite type. We still reject the pragma on interfaces, tasks,
+and protected types with entries, because it doesn't make sense there.
+
+For question 6, it appears that the petitioner is misguided. The rule he proposes
+would have weird effects: for the untagged case is it perfectly possible to have
+a parent without preelaborable initialization and a derived type with preelaborable
+initialization. There doesn't seem to be any good reason to reject a construct that
+is potentially useful.
+
+For question 7, it is obvious that the mysterious disappearance of "initialized
+by default" was not intended, as the entire purpose of the pragma is to properly
+deal with objects that are initialized by default (it has no effect in other cases).
 
 --!corrigendum A.18.2(239/2)
 
@@ -261,7 +332,7 @@
 
 We dropped the "default initialized object" part of 10.2.1(9/2), because we
 thought that it couldn't matter. I think we were wrong. Consider this example
-from text BA21002.A (case k):
+from test BA21002.A (case k):
 
    type Tag is tagged record
       C : My_Int := Func;