CVS difference for ais/ai-00366.txt

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

--- ais/ai-00366.txt	2004/04/30 02:35:39	1.6
+++ ais/ai-00366.txt	2004/05/28 00:05:48	1.7
@@ -1,4 +1,4 @@
-!standard 10.2.1                                     03-12-14  AI95-00366/02
+!standard 10.2.1                                     04-05-26  AI95-00366/03
 !class amendment 03-12-14
 !status work item 03-12-14
 !status received 03-12-14
@@ -8,8 +8,9 @@
 
 !summary
 
-Pure units allow access-to-subprogram types and access-to-object types,
-for which no storage pool is created.
+Pure units allow access-to-subprogram types and access-to-object types
+for which no storage pool is created. Furthermore, declarations in generic
+formal parts do not affect the purity of units.
 
 !problem
 
@@ -18,8 +19,8 @@
 There is no technical reason for the restriction and many packages
 that should be pure can not be declared pure.
 
-Similarly, generic formal access types should be permitted (as the storage
-pool comes from outside of the unit).
+Furthermore, there is no technical reason for including declarations
+in generic formal parts for assessing whether a unit is pure.
 
 !proposal
 
@@ -31,12 +32,41 @@
 A pure library_item is a preelaborable library_item that does not
 contain the declaration of any variable or named access type, except
 within a subprogram, generic subprogram, task unit, or protected unit.
+
 by:
+
 A pure library_item is a preelaborable library_item that does not
-contain the declaration of any variable or named access-to-object
-type, for which the Storage_Size has not been specified to be 0,
-excepting declarations within a subprogram, generic subprogram, task
-unit, or protected unit.
+contain the declaration of any variable, or named access-to-object
+type for which the Storage_Size has not been specified by a static
+expression with value 0, excepting declarations of imported variables
+and declarations within a subprogram, generic subprogram, generic
+formal part, task unit, or protected unit.
+
+Replace 10.2.1(18)
+If a library unit is declared pure, then the implementation is
+permitted to omit a call on a library-level subprogram of the library
+unit if the results are not needed after the call. Similarly, it may
+omit such a call and simply reuse the results produced by an earlier
+call on the same subprogram, provided that none of the parameters are
+of a limited type, and the addresses and values of all by-reference
+actual parameters, and the values of all by-copy-in actual parameters,
+are the same as they were at the earlier call. This permission applies
+even if the subprogram produces other side effects when called.
+
+by:
+
+If a library unit is declared pure, then the implementation is
+permitted to omit a call on a library-level subprogram of the library
+unit if the results are not needed after the call. In addition, the
+implementation may omit a call on such a subprogram and simply reuse the
+results produced by an earlier call on the same subprogram, provided
+that none of the parameters nor any object accessible via access
+values from the parameters are of a limited type, and the addresses
+and values of all by-reference actual parameters, the values of all
+by-copy-in actual parameters, and the values of all objects accessible
+via access values from the parameters, are the same as they were at
+the earlier call. This permission applies even if the subprogram
+produces other side effects when called.
 
 !discussion
 
@@ -46,17 +76,33 @@
 should not be excluded. A corresponding correction of 10.2.1(16) would
 read:
 A pure library_item is a preelaborable library_item that does not
-contain the declaration of any variable or named access-to-object type, except
-within a subprogram, generic subprogram, task unit, or protected unit.
+contain the declaration of any variable or named access-to-object type,
+except within a subprogram, generic subprogram, task unit, or protected
+unit.
 
 Beyond access-to-subprogram types, some packages have a need for an
 access-to-object type, without a need for a storage pool for the
 type, however.  Setting the Storage_size of the type to zero implies
-that no storage pool (and hence no state) needs to be created.
+that no storage pool (and hence no state) needs to be created. The
+wording is intentionally formulated to allow for easy static checking
+whether the storage size is zero.
+
+Declarations in generic formal parts do not establish state and hence
+should be added to the enumerated exclusions of the restriction on the
+presence of certain declarations. (State comes with the instantiation
+of the respective generic units.)
 
 The proposed !wording reflects these observations and removes the
-restriction on the presence of such access types.
+unnecessary restrictions.
 
+Allowing access types in Pure units means that the permission of 10.2.1(18)
+needs to be revised. The intent of the permission is that calls can be omitted
+only if it is safe (ignoring possible side-effects) because the parameters are
+the same. When access types are included, it is necessary to include the
+designated values in this check; otherwise, the designated values could be
+changed and the call still omitted. For instance, we do not want to allow the
+omission of calls on a Pure random number generator!
+
 !example
 
 --!corrigendum
@@ -1637,6 +1683,149 @@
 looks like a pretty nasty contract model violation.  What happens if
 there is such a type in the private part?  What about pure packages that
 depend on other pure packages that define an access type?
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, May 17, 2004  5:20 PM
+
+Context: I was asked to add words to AI-366 so that imported objects are
+preelaborable.
+
+Now I am confused. 99.9% of imported objects are preelaborable today, as far
+as I can tell from the RM.  The only relevant sentence that I could find is
+10.2.1(9) -- and I claim that almost all imported objects are not of a type
+cited here:
+---- << preelaborabe units may not include... >>
+* 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; similarly the evaluation of an
+extension_aggregate with an ancestor subtype_mark denoting a subtype of such
+a type.
+----
+
+o.k., our imported object could be "of a descendent of a private type", but
+as far as the rest goes, really very very unlikely.
+
+I propose to do nothing here.
+
+If you feel different, please comment also on the re-write below:
+------
+* 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, unless a pragma Import applies to
+the object (see B.1); similarly the evaluation of an
+extension_aggregate with an ancestor subtype_mark denoting a subtype of such
+a type.
+------
+
+(Incidently: this is the only occurrence of the term "default-initialized"
+ in the normative part of the RM; one more in a note of 3.8. Not exactly a
+ well defined term :-) )
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, May 17, 2004  7:16 PM
+
+> If you feel different, please comment also on the re-write below:
+
+I agree, there doesn't seem a need to change anything here, and
+adding special treatment in 10.2.1(9) for imported objects doesn't
+seem worthwhile.
+
+Since Pascal raised this issue, I guess he'll need to speak up if he
+thinks there's still an issue that needs to be addressed for imported
+objects in preelaborated packages.
+
+> (Incidently: this is the only occurrence of the term "default-initialized"
+>  in the normative part of the RM; one more in a note of 3.8. Not exactly a
+>  well defined term :-) )
+
+Note that AI-161 modifies 10.2.1(9) so that it's framed in terms of
+the new notion of types that have "preelaborable initialization".
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, May 18, 2004  1:49 AM
+
+> I propose to do nothing here.
+
+Having proposed this change you won't be surprised to hear that I disagree.
+
+> * 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, unless a pragma Import applies to
+> the object (see B.1); similarly the evaluation of an
+> extension_aggregate with an ancestor subtype_mark denoting a subtype of such
+> a type.
+
+Sounds good to me.
+
+> (Incidently: this is the only occurrence of the term "default-initialized"
+>  in the normative part of the RM; one more in a note of 3.8. Not exactly a
+> well defined term :-) )
+
+I believe (but I didn't check) that this was clarified/discussed in the AI
+that defines pragma Preelaborable_Initialization.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Tuesday, May 18, 2004  6:45 AM
+
+Pascal wrote wrt AI-366:
+> Having proposed this change you won't be surprised to hear that I disagree.
+
+Having looked now at the wording of AI-161 (and B.1(38), which states that
+an imported object is not created -- under a "notwithstanding" rule),
+all imported objects are preelaborable today and under AI-161.
+
+We need not change anything. Hence, consider my "unless clause" for 10.2.1(9)
+withdrawn from consideration.
+
+It might be worth a Note or an AARM annotations to spell out this
+ramification for imported objects. I leave that to the author of AI-161.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, May 27, 2004  6:43 PM
+
+> Replace 10.2.1(18) with
+
+> If a library unit is declared pure, then the implementation is
+> permitted to omit a call on a library-level subprogram of the library
+> unit if the results are not needed after the call.  In addition, the
+> implementation may omit a call on such a function and simply reuse the
+> results produced by an earlier call on the same function, provided
+> that none of the parameters nor any object accessible via access
+> values from the parameters are of a limited type, and the addresses
+> and values of all by-reference actual parameters, the values of all
+> by-copy-in actual parameters, and the values of all objects accessible
+> via access values from the parameters, are the same as they were at
+> the earlier call. This permission applies even if the subprogram
+> produces other side effects when called.
+
+The uses of the word "function" in the above paragraph should be
+changed to "subprogram."
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, May 27, 2004  7:05 PM
+
+The !discussion should say something about the reasons for revising 10.2.1(18).
+Therefore, I added the following to the !discussion:
+
+Allowing access types in Pure units means that the permission of 10.2.1(18)
+needs to be revised. The intent of the permission is that calls can be omitted
+only if it is safe (ignoring possible side-effects) because the parameters are
+the same. When access types are included, it is necessary to include the
+designated values in this check; otherwise, the designated values could be
+changed and the call still omitted. For instance, we do not want to allow the
+omission of calls on a Pure random number generator!
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent