CVS difference for ais/ai-00161.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00161.txt

--- ais/ai-00161.txt	1999/03/01 19:15:23	1.6
+++ ais/ai-00161.txt	1999/03/13 01:36:17	1.7
@@ -1,4 +1,4 @@
-!standard 10.02.01 (09)                               99-02-23  AI95-00161/03
+!standard 10.02.01 (09)                               99-03-12  AI95-00161/04
 !class binding interpretation 99-02-23
 !status work item 98-04-16
 !status received 96-09-10
@@ -40,7 +40,7 @@
 
 (See wording.)
 
-!wording 99-02-23
+!wording 99-03-12
 
 Change the RM95 10.2.1(9) to read:  "The creation of an object (including a
 component) of a subtype which does not have preelaborable initialization.
@@ -52,52 +52,21 @@
 formal derived type whose ancestor subtype is tagged, or a descendant of such
 a type."
 
-!discussion 99-02-23
+Add the following after RM95 10.2.1(11):
 
-1. A "default-initialized object" is an object for which the implicit
-initialization described in RM95 3.3.1(10-14) takes place.  Examples of
-default-initialized objects include an object_declaration without an
-initialization expression, and the (anonymous) object created by the
-evaluation of an extension_aggregate whose ancestor_part is a subtype name.
-
-Note that an object of a task type or of a protected type is always default-
-initialized.  Also note that for a private type or a private extension,
-providing an initialization expression always requires a reference to the
-name of an object, or a call to a non-static function, which are forbidden by
-other rules.  Finally note that for a controlled type, an initialization
-expression may also be provided by an extension aggregate (if visibility
-allows), which must have a controlled subtype name as the ancestor part,
-which is forbidden.
-
-The conclusion is that the phrase "default-initialized" can be removed from
-RM95 10.2.1(9).
-
-2. RM95 10.2.1(9) is indeed too restrictive.  For preelaboration to be usable
-(in particular in the context of distributed systems) we must loosen up the
-rules dramatically.  However, we do not want to impose an additional burden
-on implementations which support annex C and have to comply with the
-requirements of RM95 C.4.  Therefore, each time we remove a restriction from
-RM95 10.2.1(9), we must add a corresponding restriction to RM95 C.4.
-
-Clearly we must keep task objects and protected objects with entries in RM95
-10.2.1(9).  Note that the current wording seems to allow the creation of
-objects of entry-less protected types, which is strange since the
-component_declarations may include default_expressions which execute non-
-trivial code.
+"The following rules specify which entities have preelaborable
+initialization:
 
-In discussing private types, private extensions and controlled types, it is
-useful to introduce the notion of some entities "having preelaborable
-initialization."
-
-- The partial view of a private type or private extension, a generic formal
-private type, or a generic formal derived type whose ancestor subtype is
-tagged, have preelaborable initialization if and only if the pragma
-Preelaborable_Initialization has been applied to them.
+- 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 whose ancestor subtype is tagged, have preelaborable
+initialization if and only if the pragma Preelaborable_Initialization has
+been applied to them.
+
+- Task types and protected types with entry_declarations do not have
+preelaborable initialization; controlled types which have an overriden
+Initialize do not have preelaborable initialization.
 
-- Task types and protected types do not have preelaborable initialization;
-controlled types which have an overriden Initialize do not have preelaborable
-initialization.
-
 - A view of a type has preelaborable initialization if it is an elementary
 type, an array type whose component subtype has preelaborable initialization,
 a record type whose components all have preelaborable initialization, a
@@ -105,11 +74,11 @@
 case of a record extension) whose components all have preelaborable
 initialization.
 
-- A record component (including a discriminant) has preelaborable
-initialization if its declaration includes a default_expression whose
-execution does not perform any of the actions listed in RM95 10.2.1(6-9), or
-if its declaration does not include a default expression and its nominal
-subtype 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 of the actions listed in RM95 10.2.1(6-
+9), or if its declaration does not include a default expression and its
+nominal subtype has preelaborable initialization.
 
 - A constrained subtype of a record type has preelaborable initialization if
 all its non-discriminant components have preelaborable initialization.
@@ -117,11 +86,6 @@
 - Other subtypes have preelaborable initialization if their base type has
 preelaborable initialization.
 
-Having defined the notion of preelaborable initialization, we allow the
-creation, in preelaborable units, of objects whose nominal subtype has
-preelaborable initialization.  The restrictions which used to appear in RM95
-10.2.1(9) are moved to RM95 C.4.
-
 A pragma Preelaborable_Initialization specifies that a type has preelaborable
 initialization.  The form of this pragma is as follows:
 
@@ -132,20 +96,67 @@
 
 In the first case, the enclosing library unit shall be the declaration of a
 preelaborated package.  The direct_name shall denote the first subtype of a
-private type or a private extension declared within the same package visible
-part as the pragma.  The full view of the type denoted by the direct_name
-shall have preelaborable initialization.  In addition to the places where
-Legality Rules normally apply, this rule applies also in the private part of
-an instance of a generic unit.
+protected type without entry_declarations, private type or private extension
+declared within the same package visible part as the pragma.
 
+In the direct_name denotes a private type or a private extension, the full
+view of the type shall have preelaborable initialization.  If the direct_name
+denotes a protected type, each component of the protected 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.
+
 In the second case, 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.  Moreover, if the direct_name denotes a formal derived
 type, the ancestor subtype shall be a tagged type.  If the pragma
 Preelaborable_Initialization is applied to a formal type, in a
 generic_instantiation the actual type shall have preelaborable
-initialization.
+initialization."
 
+!discussion 99-03-12
+
+1. A "default-initialized object" is an object for which the implicit
+initialization described in RM95 3.3.1(10-14) takes place.  Examples of
+default-initialized objects include an object_declaration without an
+initialization expression, and the (anonymous) object created by the
+evaluation of an extension_aggregate whose ancestor_part is a subtype name.
+
+Note that an object of a task type or of a protected type is always default-
+initialized.  Also note that for a private type or a private extension,
+providing an initialization expression always requires a reference to the
+name of an object, or a call to a non-static function, which are forbidden by
+other rules.  Finally note that for a controlled type, an initialization
+expression may also be provided by an extension aggregate (if visibility
+allows), which must have a controlled subtype name as the ancestor part,
+which is forbidden.
+
+The conclusion is that the phrase "default-initialized" can be removed from
+RM95 10.2.1(9).
+
+2. RM95 10.2.1(9) is indeed too restrictive.  For preelaboration to be usable
+(in particular in the context of distributed systems) we must loosen up the
+rules dramatically.  However, we do not want to impose an additional burden
+on implementations which support annex C and have to comply with the
+requirements of RM95 C.4.  Therefore, each time we remove a restriction from
+RM95 10.2.1(9), we must add a corresponding restriction to RM95 C.4.
+
+Clearly we must keep task objects and protected objects with entries in RM95
+10.2.1(9).  Note that the current wording seems to allow the creation of
+objects of entry-less protected types, which is strange since the
+component_declarations may include default_expressions which execute non-
+trivial code.
+
+To precisely specify which object declarations are acceptable in a
+preelaborable unit, we introduce the notion of a type having preelaborable
+initialization.  In order to take advantage of the fact that some two-part
+types (such as private types and private extensions) may have preelaborable
+initialization, without breaking the privacy of private types, we introduce
+the pragma Preelaborable_Initialization.  This pragma is applied to the
+partial view, and it promises that the full view will have preelaborable
+initialization.  This pragma is applied to some of the predefined private
+types, to make it easier for users to write preelaborable units.
+
 The following table lists all the private types and private extensions
 declared in preelaborated predefined packages.  For each such type, the table
 specifies if a pragma Preelaborable_Initialization is applied to the type
@@ -322,44 +333,6 @@
 
 What do you think?
 
-> There seem to be two solutions.  One
-> is to allow stream attributes to be specified before the
-> type is fully defined.  The other is to allow them to be specified
-> in the private part.
-
-I hate to open private parts.  In our compiler, this is a real nightmare (we
-have to do that for pragma Convention, and that's already a big pain in the
-neck).
-
-So my preference would be to allow the specification of stream attributes
-before the type is fully defined.  Remember that we already have an AI that
-says that 13.1(10) does not apply to stream attributes.  This would just be
-another oddity with stream-oriented attributes.  (In fact I believe the
-stream-oriented attributes should not be considered a representation item,
-since they do not affect the physical representation of the type; they should
-be "something else", with much more relaxed rules; but we are not going to
-rewrite chapter 13...)
-
-> I suppose another option is to have some
-> kind of "incomplete" stream attribute specification,
-> such as "for Lim_Type'Read use <>;" in the visible part,
-> and then complete the definition in the private part.  This is
-> rampant invention, of course, but it solves another problem.
-
-This would have been a nice idea in '93, but at this point I think the
-language is insufficiently broken to invent new syntax.
-
-> Types like Exception_Occurrence are required to have stream attributes,
-> but not have any other primitive operations declared in the
-> visible part.  However stream attributes can only be defined
-> in terms of some "normal" subprogram, which must necessarily also
-> be visible at the point of the stream attribute definition.
-> Another contradiction...
-
-If there is a problem with this package, then I'd rather see the ARG modify
-the specification of Ada.Exceptions to include the additional stuff needed for
-streaming, rather than adding new syntax for this cornercase.
-
 Pascal
 
 ****************************************************************
@@ -394,55 +367,6 @@
 object, since the only use of the type is for that object, and
 if that object is in a preelaborated package, clearly the
 default initialization needs to be preelaborable.
-
-> ...
-
-> > There seem to be two solutions.  One
-> > is to allow stream attributes to be specified before the
-> > type is fully defined.  The other is to allow them to be specified
-> > in the private part.
->
-> I hate to open private parts.  In our compiler, this is a real nightmare (we
-> have to do that for pragma Convention, and that's already a big pain in the
-> neck).
->
-> So my preference would be to allow the specification of stream attributes
-> before the type is fully defined.  Remember that we already have an AI that
-> says that 13.1(10) does not apply to stream attributes.  This would just be
-> another oddity with stream-oriented attributes.  (In fact I believe the
-> stream-oriented attributes should not be considered a representation item,
-> since they do not affect the physical representation of the type; they should
-> be "something else", with much more relaxed rules; but we are not going to
-> rewrite chapter 13...)
-
-Yes, I agree, since 13.1(10) does not apply to stream attributes, we
-should view them as a special category of attribute, and allow them
-to be specified on private types and other not-yet-completely-defined
-types.
-
-> > I suppose another option is to have some
-> > kind of "incomplete" stream attribute specification,
-> > such as "for Lim_Type'Read use <>;" in the visible part,
-> > and then complete the definition in the private part.  This is
-> > rampant invention, of course, but it solves another problem.
->
-> This would have been a nice idea in '93, but at this point I think the
-> language is insufficiently broken to invent new syntax.
->
-> > Types like Exception_Occurrence are required to have stream attributes,
-> > but not have any other primitive operations declared in the
-> > visible part.  However stream attributes can only be defined
-> > in terms of some "normal" subprogram, which must necessarily also
-> > be visible at the point of the stream attribute definition.
-> > Another contradiction...
->
-> If there is a problem with this package, then I'd rather see the ARG modify
-> the specification of Ada.Exceptions to include the additional stuff needed for
-> streaming, rather than adding new syntax for this cornercase.
-
-If we allow specification of stream attributes on private types, that
-will probably simplify the solution enough to not justify adding any
-declarations to Ada.Exceptions.
 
 -Tuck
 

Questions? Ask the ACAA Technical Agent