CVS difference for ais/ai-00161.txt

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

--- ais/ai-00161.txt	1998/10/01 03:20:17	1.3
+++ ais/ai-00161.txt	1999/02/28 00:31:16	1.4
@@ -1,32 +1,34 @@
-!standard 10.02.01 (09)                               98-04-16  AI95-00161/01
-!class confirmation 96-09-10
+!standard 10.02.01 (09)                               99-02-23  AI95-00161/03
+!class binding interpretation 99-02-23
 !status work item 98-04-16
 !status received 96-09-10
 !priority Medium
 !difficulty Medium
 !subject Default-initialized objects
 
-!summary 98-04-16
+!summary 99-02-23
 
+The creation of an object whose nominal subtype has preelaborable
+initialization is allowed in a preelaborable unit.  This makes it possible to
+declare objects of some private types in preelaborable units.
+
 The notion of a subtype having "preelaborable initialization" is defined by
 this AI.
-
-The creation of an object whose nominal subtype has preelaborable
-initialization is allowed in a preelaborable unit.
 
-!question 98-04-16
+!question 99-02-23
 
-RM95 10.2.1(9) states that: "The creation of a default-initialized object
-(including a component) of a descendant of a private type, private
-extension, controlled type, task type or protected type with entry
-declarations."
+The paragraphs RM95 10.2.1(5-9) list a number of constructs which are
+forbidden in preelaborable units.  In particular, RM95 10.2.1(9) states that:
+"The creation of a default-initialized object (including a component) of a
+descendant of a private type, private extension, controlled type, task type
+or protected type with entry declarations."
 
 1. In this rule, what is the meaning of "default-initialized object"?
 
 2. This rule seems extremely restrictive.  For instance, if (as recommended)
 System.Address is a private type, the declaration:
 
-	A : System.Address;
+        A : System.Address;
 
 makes the enclosing unit non-preelaborable.  As another example, the
 implementation of Ada.Strings.Unbounded suggested in the Rationale is
@@ -38,46 +40,44 @@
 
 (See wording.)
 
-!wording 98-04-16
+!wording 99-02-23
 
 Change the RM95 10.2.1(9) to read:  "The creation of an object (including a
-component) of a subtype which doesn't have preelaborable initialization.
+component) of a subtype which does not have preelaborable initialization.
 Similarly the evaluation of an extension_aggregate with an ancestor
 subtype_mark denoting such a subtype."
 
-Add after C.4(1): "The requirements stated in this section only apply to units
-which do not create objects (including components) of a descendant of a
-private type, private extension, controlled type, task type or protected type;
-similarly, which do not evaluate extension_aggregates with an ancestor
-subtype_mark denoting a subtype of such a type."
+Add a new bullet after C.4(4): "No subtype_mark denotes a controlled type, a
+private type, a private extension, a generic formal private type, a generic
+formal derived type whose ancestor subtype is tagged, or a descendant of such
+a type."
 
-!discussion 98-04-16
+!discussion 99-02-23
 
 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.
+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.
+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.
+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
@@ -89,26 +89,27 @@
 useful to introduce the notion of some entities "having preelaborable
 initialization."
 
-- The partial view of a private type or private extension doesn't have
-preelaborable initialization, unless it is one of the predefined types listed
-below.
+- 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.
 
-- Task types and protected types don't have preelaborable initialization;
-controlled types which have an overriden Initialize don't have preelaborable
+- Task types and protected types do not have preelaborable initialization;
+controlled types which have an overriden Initialize do not have preelaborable
 initialization.
 
-- The full 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 derived type whose parent type has preelaborable
-initialization and (in the case of a record extension) whose components all
-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
+derived type whose parent type has preelaborable initialization and (in the
+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 doesn't perform any of the actions listed in RM95 10.2.1(6-9), or if
-its declaration doesn't include a default expression and its nominal subtype
-has preelaborable initialization.
+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.
@@ -116,55 +117,62 @@
 - Other subtypes have preelaborable initialization if their base type has
 preelaborable initialization.
 
-- The following table lists all the private types and private extensions
-declared in the predefined packages, and specify if they have preelaborable
-initialization (yes) or not (no).  For those packages that have a Wide_
-variant, the types declared in the Wide_ variant have the same classification
-as the types declared in the 'narrow' variant.  The same remark applies to the
-non-generic equivalents of the various generic packages.
-
-Ada.Calendar.Time
-							yes
-Ada.Direct_IO.File_Type							no
-Ada.Exceptions.Exception_Id						yes
-Ada.Exceptions.Exception_Occurrence					yes
-Ada.Finalization.Controlled						yes
-Ada.Finalization.Limited_Controlled					yes
-Ada.Numerics.Discrete_Random.Generator				no
-Ada.Numerics.Discrete_Random.State					yes
-Ada.Numerics.Float_Random.Generator					no
-Ada.Numerics.Float_Random.State					yes
-Ada.Numerics.Generic_Complex_Types.Imaginary			yes
-Ada.Sequential_IO.File_Type						no
-Ada.Streams.Root_Stream_Type						yes
-Ada.Streams.Stream_IO.File_Type					no
-Ada.Strings.Bounded.Generic_Bounded_Length.Bounded_String	no
-Ada.Strings.Maps.Character_Mapping					no
-Ada.Strings.Maps.Character_Set					no
-Ada.Strings.Unbounded.Unbounded_String				no
-Ada.Text_IO.File_Type							no
-Ada.Tags.Tag								yes
-Ada.Task_Identification.Task_Id					yes
-Interfaces.C.Strings.Chars_Ptr					yes
-System.Address								yes
-System.Storage_Pool.Root_Storage_Pool				yes
-
-Note: The types marked 'no' above are types for which an implementation might
-want to use protected types internally to allow concurrent use of the same
-object by several tasks.  While this is no required by the RM, it seems that
-we don't want to prevent implementations from doing this sort of things.
-
-We plan to introduce a pragma to specify, when declaring the partial view of a
-private type or private extension, that the full view has preelaborable
-initialization.  This will make it possible for users to declare a private
-type with preelaborable initialization, without violating the privacy of
-private types.  This pragma will be the subject of another AI.
-
 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:
+
+        pragma Preelaborable_Initialization (direct_name);
+
+This pragma must appear (1) in the visible part of a package, or (2) in the
+formal part of a generic library package.
+
+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.
+
+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.
+
+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
+(yes) or not (no).  For those packages that have a Wide_ variant, the types
+declared in the Wide_ variant have the same classification as the types
+declared in the 'narrow' variant.  The same remark applies to the non-generic
+equivalents of the various generic packages.
+
+Ada.Calendar.Time                                                               yes
+Ada.Finalization.Controlled                                             yes
+Ada.Finalization.Limited_Controlled                                     yes
+Ada.Numerics.Generic_Complex_Types.Imaginary                    yes
+Ada.Streams.Root_Stream_Type                                            yes
+Ada.Strings.Bounded.Generic_Bounded_Length.Bounded_String       no
+Ada.Strings.Maps.Character_Mapping                                      yes
+Ada.Strings.Maps.Character_Set                                  yes
+Ada.Strings.Unbounded.Unbounded_String                          yes
+Interfaces.C.Strings.Chars_Ptr                                  yes
+System.Address                                                          yes
+System.Storage_Pool.Root_Storage_Pool                           yes
+
+Note: The type Bounded_String cannot have a pragma
+Preelaborable_Initialization, because that would make it impossible to
+instantiate Generic_Bounded_Length with a non-static expression for the
+parameter Max.
+
+
 
 !appendix 96-09-10
 
@@ -176,11 +184,13 @@
 !discussion
 
 The referenced paragraph says that a construct is not preelaborable if it
-performs "The creation of a default-initialized object (including a component)
+performs "The creation of a default-initialized object (including a
+component)
 of a descendant of a private type, private extension, controlled type, task
 type or protected type with entry declarations;"
 
-In this rule, what is the meaning of "default-initialized object"?  I couldn't
+In this rule, what is the meaning of "default-initialized object"?  I
+couldn't
 find a definition of this phrase.
 
 Bob Duff (private communication) tells me that this phrase is intended to
@@ -202,14 +212,15 @@
 extension, or a controlled type.  Is it the intent?
 
 (It looks like all objects of task or protected types are
-"default-initialized", so the rule is redundant.  But that's not important: it
+"default-initialized", so the rule is redundant.  But that's not important:
+it
 is clear that we don't want objects of such types in preelaborated units.)
 
 ****************************************************************
 
-From: 	Randy Brukardt [SMTP:Randy@rrsoftware.com]
-Sent: 	Thursday, May 07, 1998 8:12 PM
-Subject: 	Re: AI95-00161/02
+From:   Randy Brukardt [SMTP:Randy@rrsoftware.com]
+Sent:   Thursday, May 07, 1998 8:12 PM
+Subject:        Re: AI95-00161/02
 
 This AI has class "Confirmation", yet proposes language which extends the
 language (allowing things previously disallowed).  I wouldn't expect
@@ -218,9 +229,9 @@
 
 ****************************************************************
 
-From: 	Pascal Leroy[SMTP:phl@Rational.Com]
-Sent: 	Friday, May 08, 1998 6:04 AM
-Subject: 	Re: AI95-00161/02
+From:   Pascal Leroy[SMTP:phl@Rational.Com]
+Sent:   Friday, May 08, 1998 6:04 AM
+Subject:        Re: AI95-00161/02
 
 > This AI has class "Confirmation", yet proposes language which extends the
 > language (allowing things previously disallowed).  I wouldn't expect
@@ -230,5 +241,47 @@
 Surely it should be a binding interpretation.  Thanks for noticing.
 
 Pascal
+
+****************************************************************
+
+From: 	Tucker Taft
+Sent: 	Friday, February 26, 1999 9:47 AM
+Subject: 	Re: Updated AIs
+
+In AI 131, you have proposed that entry-less protected
+objects are not preelaborable.  This is a troublesome
+change, as Shared_Passive packages are required to
+be preelaborable, and entry-less protected objects are
+the only means of synchronization available via a
+Shared_Passive partition.
+
+Hence, the AI needs to accommodate entry-less protected objects
+somehow, ideally without causing incompatibilities with
+existing code which uses Shared_Passive packages, though
+that goal may not be achievable...
+
+-Tuck
+
+****************************************************************
+
+From: 	Randy Brukardt
+Sent: 	Friday, February 26, 1999 3:06 PM
+Subject: 	RE: Updated AIs
+
+Tucker writes:
+
+>In AI 131, you have proposed that entry-less protected
+>objects are not preelaborable.
+
+You mean AI 161. 131 is on interfacing to C.
+
+Randy's comments on AI-161:
+
+There is something wrong with the Wording change in this AI, as it depends on the
+(undefined) term "preelaboratable initialization". I think the entire definition of this
+term, and the pragma, needs to be moved to the "Wording" section. That would
+leave just the actual discussion behind, not the technical definition.
+
+				Randy.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent