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

--- ai05s/ai05-0157-1.txt	2009/12/10 07:23:13	1.4
+++ ai05s/ai05-0157-1.txt	2009/12/29 05:02:48	1.5
@@ -1,6 +1,8 @@
-!standard 13.11.2(4)                                   09-12-09  AI05-0157-1/02
+!standard 4.8(5.3/2)                                   09-12-10  AI05-0157-1/03
+!standard 13.11.2(4)
 !standard 13.11.2(17)
 !class binding interpretation 09-06-02
+!status Amendment 201Z 09-12-10
 !status ARG Approved 10-0-1  09-11-08
 !status work item 09-06-02
 !status received 09-02-15
@@ -36,6 +38,8 @@
 
 !wording
 
+Delete the last sentence of 4.8(5.3/2).
+
 Add before 13.11.2(4):
 
 Legality Rules
@@ -45,10 +49,6 @@
 specified by a static expression with value zero or is defined by the language
 to be zero. In addition to the places where Legality Rules normally apply (see
 12.3), this rule applies also in the private part of an instance of a generic unit.
-This rule does not apply in the body of a generic unit or within a body declared
-within the declarative region of a generic unit, if the actual access type of
-the instance is a descendant of a formal access type declared within the formal
-part of the generic unit.
 
 [Editor's note: This is nearly a copy of 4.8(5.3/2).]
 
@@ -57,7 +57,7 @@
 A call on an instance of Unchecked_Deallocation with a non-null access value should
 raise Program_Error if the actual access type of the instance is a type for which
 the Storage_Size has been specified to be zero or is defined by the language to be
-zero. 
+zero.
 
 AARM Note: If the call is not illegal (as in a generic body), we recommend that
 it raise Program_Error. Since the execution of this call is erroneous (any allocator
@@ -117,6 +117,44 @@
 for option (4) if the call is legal but the size is known to be zero.
 
 
+We delete the last line of 4.8(5.3/2) and do not add a similar line to
+the new text. That line read: "This rule does not apply in the body
+of a generic unit or within a body declared within the declarative region
+of a generic unit, if the type of the allocator is a descendant of a
+formal access type declared within the formal part of the generic unit."
+However, this cannot usefully happen. For a formal access type, the
+Storage_Size is not known and surely isn't static, so the legality rules can never
+apply. For a formal derived type, the legality rules can only be triggered
+by a parent type having the appropriate property. But Storage_Size can
+never be specified for a derived access type, so it always has the same
+value for all child types. That means that any actual that would match
+the formal derived type necessarily has the same Storage_Size properties,
+so it is harmless (and preferable) to check them in the body - they are
+always known in that case. We cannot imagine changing this particular
+invariant, as it is necessary so that (potentially implicit) type
+conversions between derived access types are safe, so there is no
+maintenance hazard potential from omitting the rule.
+
+
+!corrigendum 4.8(5.3/2)
+
+@drepl
+An @fa<allocator> shall not be of an access type for which the Storage_Size
+has been specified by a static expression with value zero or is defined by
+the language to be zero. In addition to the places where Legality Rules
+normally apply (see 12.3), this rule applies also in the private part
+of an instance of a generic unit. This rule does not apply in the body
+of a generic unit or within a body declared within the declarative region
+of a generic unit, if the type of the allocator is a descendant of a
+formal access type declared within the formal part of the generic unit.
+@dby
+An @fa<allocator> shall not be of an access type for which the Storage_Size
+has been specified by a static expression with value zero or is defined by
+the language to be zero. In addition to the places where Legality Rules
+normally apply (see 12.3), this rule applies also in the private part
+of an instance of a generic unit.
+
+
 !corrigendum 13.11.2(4)
 
 @dinst
@@ -129,10 +167,6 @@
 specified by a static expression with value zero or is defined by the language
 to be zero. In addition to the places where Legality Rules normally apply (see
 12.3), this rule applies also in the private part of an instance of a generic unit.
-This rule does not apply in the body of a generic unit or within a body declared
-within the declarative region of a generic unit, if the actual access type of
-the instance is a descendant of a formal access type declared within the formal
-part of the generic unit.
 
 !corrigendum 13.11.2(17)
 
@@ -142,7 +176,7 @@
 A call on an instance of Unchecked_Deallocation with a non-null access value should
 raise Program_Error if the actual access type of the instance is a type for which
 the Storage_Size has been specified to be zero or is defined by the language to be
-zero. 
+zero.
 
 
 !ACATS Test
@@ -398,5 +432,57 @@
 to be spelled as generics, but I don't see that we should let this aversion
 cripple the definition in any way. In particular the rules for erroneousness are
 already special.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, December 10, 2009  1:21 AM
+
+In St. Pete, someone complained that the last sentence of the new wording for
+13.11.2(3.1/3) is unnecessary:
+
+A call on an instance of Unchecked_Deallocation is illegal if the actual access
+type of the instance is a type for which the Storage_Size has been specified by
+a static expression with value zero or is defined by the language to be zero. In
+addition to the places where Legality Rules normally apply (see 12.3), this rule
+applies also in the private part of an instance of a generic unit. This rule
+does not apply in the body of a generic unit or within a body declared within
+the declarative region of a generic unit, if the actual access type of the
+instance is a descendant of a formal access type declared within the formal part
+of the generic unit.
+
+The thinking was that a generic formal access type never has a static value for
+Storage_Size. There is an unusual case: that a generic formal derived type has a
+parent access type that does have such a static value; but in that case, all
+child types that would match the formal derived type also must have that static
+value. So there would be no harm in applying the rule.
+
+I argued that we shouldn't make a change because it is exactly the same as the
+allocator rule, which was considered decisive.
+
+But I missed the more important question: why is this sentence in the allocator
+rule as well? The same points apply to it. AI95-0366-1 does not explain why this
+sentence was included - it doesn't seem to be needed for allocators, either. In
+any case, the legality rule (like any other legality rule) doesn't apply in the
+bodies of instances, so that can't be the problem.
+
+I wondered if it had anything to do with the other case: "defined by the
+language to be zero". That's code for "remote types". But I don't think a
+generic formal access type can be a remote access type. (A formal derived type
+can be, but that again would not need any exceptions.)
+
+So I suspect that the last sentence can be dropped from both 4.8(5.3/2) and the
+new 13.11.2(3.1/3). Unless Steve can remember some obscure case involving child
+generic units and/or formal packages.
+
+Any other thoughts??
+
+****************************************************************
+
+From the minutes of the Amendement Subcommittee conference call of
+December 10th:
+
+Drop the extra sentence from both paragraphs. Explain in the AARM why there is
+no problem that requires this extra sentence.
 
 ****************************************************************