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

Differences between 1.5 and version 1.6
Log of other versions for file ai05s/ai05-0041-1.txt

--- ai05s/ai05-0041-1.txt	2008/02/06 01:44:29	1.5
+++ ai05s/ai05-0041-1.txt	2008/03/07 06:15:19	1.6
@@ -1,9 +1,12 @@
-!standard 3.7.1(7/2)                                          08-02-05    AI05-0041-1/05
+!standard 3.7.1(7/2)                                          08-02-22    AI05-0041-1/06
 !standard 3.3(27.9/3)
 !standard 3.3(27.10/3)
+!standard 3.10.2(26/3)
 !standard 3.10.2(27.2/2)
+!standard 3.10.2(28)
 !standard 4.8(6/2)
 !class binding interpretation 07-03-27
+!status ARG Approved  5-0-3  08-02-09
 !status work item 07-03-27
 !status received 07-03-27
 !priority Medium
@@ -21,7 +24,7 @@
 !question
 
 (1) It seems that the meaning of "partial view" in 3.7.1(7/2) is either
-obscure or too narrow. The ACATS 2.6 test contains an subtest like the following,
+obscure or too narrow. The ACATS 2.6 test contains a subtest like the following,
 for which the legality is not obvious.
 
 package B371001_1 is
@@ -119,7 +122,7 @@
 
 !recommendation
 
-(See Summary.)
+(See summary.)
 
 !wording
 
@@ -135,7 +138,7 @@
   object is known to be constrained:
 
      * if a subtype is a descendant of an untagged generic formal
-       derived type, and the subtype is not an unconstrained array
+       private or derived type, and the subtype is not an unconstrained array
        subtype, it is not considered indefinite and is considered to
        have a constrained partial view;
 
@@ -146,20 +149,44 @@
 
    ... However, in the case of an access subtype, a discriminant_
    constraint is {legal only if any dereference of a value of the access
-   type is known to be constrained (see 3.3).} [... rest of paragraph
-   deleted ...]
+   type is known to be constrained (see 3.3).} [illegal if the designated
+   type has a partial view that is constrained or, for a general access
+   subtype, has default_expressions for its discriminants.]
+   In addition to the places where Legality Rules normally apply (see 12.3),
+   these rules apply also in the private part of an instance of a generic unit.
+   [In a generic body, this rule is checked presuming all formal access types
+   of the generic might be general access types, and all untagged
+   discriminated formal types of the generic might have default_expressions
+   for their discriminants.]
+
+Change 3.10.2(26/3) as modified by AI05-0008-1 as follows:
+
+ * The view shall not be a subcomponent that depends on discriminants of
+   an object unless the object is known to be constrained. [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.]
 
 Change 3.10.2(27.2/2) as follows:
  
-   
  * D shall be discriminated in its full view and unconstrained in any 
    partial view, and the designated subtype of A shall be unconstrained.
    {For the purposes of determining within a generic body whether D is
    unconstrained in any partial view, a discriminated subtype is is
    considered to have a constrained partial view if it is a descendant
-   of an untagged generic formal private or derived type. 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.}
+   of an untagged generic formal private or derived type.}
+
+Change 3.10.2(28) as follows:
+
+ * The accessibility level of the view shall not be statically deeper than
+   that of the access type A. [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.]
+
+ In addition to the places where Legality Rules normally apply (see 12.3),
+ these requirements apply also in the private part of an instance of a
+ generic unit.
+
+[Editor's note: This last paragraph is not a bullet or within a bullet.]
 
 Change 4.8(6/2) as follows:
 
@@ -267,8 +294,128 @@
    
 A bit of a double negative, unfortunately.
 
---!corrigendum 3.10.2(27.2/2)
+The generic boilerplate has to be added to 3.10.2(27.2/2). AI05-0008-1 added
+it to 3.10.2(26/2). It is already in 3.10.2(28). It is better to have
+that apply to *all* of the bullets here, for consistency if for no other reason.
+It is weird to have some, but not all, of the rules apply to an access attribute
+in the private part of a generic unit.
+
+!corrigendum 3.3(23.9/3)
+
+@drepl
+@xbullet<it is a dereference of a pool-specific access type, and there is no partial
+view of its type that is constrained.>
+@dby
+@xbullet<it is a dereference of a pool-specific access type, and there is
+no ancestor of its type that has a constrained partial view.>
+
+!corrigendum 3.3(23.10/3)
+
+@drepl
+For the purposes of determining within a generic body whether an object is known to be
+constrained, a subtype is not considered indefinite if it is a descendant of an untagged
+generic formal derived type, nor is an access type considered pool-specific if it is a
+descendant of a formal access type.
+@dby
+For the purposes of determining within a generic body whether an
+object is known to be constrained:
+
+@xbullet<if a subtype is a descendant of an untagged generic formal
+private or derived type, and the subtype is not an unconstrained array
+subtype, it is not considered indefinite and is considered to
+have a constrained partial view;>
+
+@xbullet<if a subtype is a descendant of a formal access type, it is not
+considered pool-specific.>
+
+
+!corrigendum 3.7.1(7/2)
+
+@drepl
+A @fa<discriminant_constraint> is only allowed in a
+@fa<subtype_indication> whose @fa<subtype_mark> denotes
+either an unconstrained discriminated subtype, or an
+unconstrained access subtype whose designated subtype is
+an unconstrained discriminated subtype.
+However, in the case of an access subtype, a @fa<discriminant_constraint>
+is illegal if the designated type has a partial view that is constrained
+or, for a general access subtype, has @fa<default_expression>s for its
+discriminants.
+In addition to the places where Legality Rules normally apply (see 12.3),
+these rules apply also in the private part of an instance
+of a generic unit. In a generic body, this rule is checked presuming all
+formal access types of the generic might be general access types, and
+all untagged discriminated formal types of the generic might have
+@fa<default_expression>s for their discriminants.
+@dby
+A @fa<discriminant_constraint> is only allowed in a
+@fa<subtype_indication> whose @fa<subtype_mark> denotes
+either an unconstrained discriminated subtype, or an
+unconstrained access subtype whose designated subtype is
+an unconstrained discriminated subtype.
+However, in the case of an access subtype, a @fa<discriminant_constraint>
+is legal only if any dereference of a value of the access
+type is known to be constrained (see 3.3).
+In addition to the places where Legality Rules normally apply (see 12.3),
+these rules apply also in the private part of an instance of a generic unit.
+
+!corrigendum 3.10.2(26/3)
+
+@drepl
+@xinbull<The view shall not be a subcomponent that depends on discriminants of
+an object unless the object is known to be constrained. 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.>
+@dby
+@xinbull<The view shall not be a subcomponent that depends on discriminants of
+an object unless the object is known to be constrained.>
+
+!corrigendum 3.10.2(27.2/2)
+
+@drepl
+@xi2bull<@i<D> shall be discriminated in its full view and unconstrained in any 
+partial view, and the designated subtype of @i<A> shall be unconstrained.
+@dby
+@xi2bull<@i<D> shall be discriminated in its full view and unconstrained in any 
+partial view, and the designated subtype of @i<A> shall be unconstrained.
+For the purposes of determining within a generic body whether @i<D> is
+unconstrained in any partial view, a discriminated subtype is is
+considered to have a constrained partial view if it is a descendant
+of an untagged generic formal private or derived type.
+
+!corrigendum 3.10.2(28)
+
+@drepl
+@xbullet<The accessibility level of the view shall not be statically deeper than
+that of the access type A. 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.>
+@dby
+@xbullet<The accessibility level of the view shall not be statically deeper than
+that of the access type A.>
 
+In addition to the places where Legality Rules normally apply (see 12.3),
+these requirements apply also in the private part of an instance of a
+generic unit.
+
+!corrigendum 4.8(6/2)
+
+@drepl
+If the designated type of the type of the @fa<allocator> is elementary, then
+the subtype of the created object is the designated subtype. If the designated
+type is composite, then the subtype of the created object is the designated
+subtype when the designated subtype is constrained or there is a partial view
+of the designated type that is constrained; otherwise, the created object is
+constrained by its initial value (even if the designated subtype is
+unconstrained with defaults).
+@dby
+If the designated type of the type of the @fa<allocator> is elementary, then
+the subtype of the created object is the designated subtype. If the designated
+type is composite, then the subtype of the created object is the designated
+subtype when the designated subtype is constrained or there is an ancestor
+of the designated type that has a constrained partial view; otherwise,
+the created object is constrained by its initial value (even if the
+designated subtype is unconstrained with defaults).
 
 
 !ACATS test
@@ -1223,5 +1370,87 @@
 
 and then take it out of 3.10.2(26), 3.10.2(27.2), and 3.10.2(28).
 ["requirements" echos the lead-in in 3.10.2(24)]
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, February 22, 2008  9:17 PM
+
+The wording we approved in St. Pete Beach seems to not quite cover all of
+the cases. Or I've missed something.
+
+The old wording of 3.7.1(7/2) has:
+
+In a generic body, this rule is checked presuming all formal access types
+of the generic might be general access types, and all untagged
+discriminated formal types of the generic might have default_expressions
+for their discriminants.
+
+This text was deleted; the idea being that it was folded into the definition
+of "known to be constrained".
+
+The new definition of "known to be constrained" says:
+
+For the purposes of determining within a generic body whether an
+object is known to be constrained:
+
+* if a subtype is a descendant of an untagged generic formal
+derived type, and the subtype is not an unconstrained array
+subtype, it is not considered indefinite and is considered to
+have a constrained partial view;
+
+* if a subtype is a descendant of a formal access type, it is not
+considered pool-specific.
+
+This wording makes a special case for untagged generic formal derived types,
+and it covers the cases mentioned by the old wording (although rather
+differently).
+
+But "untagged discriminated formal types" include untagged generic formal
+private types. The new wording doesn't seem to include them. I think they
+need to be included; indeed, the question (2) gives an example that includes
+a generic formal private type. So I don't think the wording as proposed
+actually fixes question (2).
+
+This is easily fixed (I think) by adding "or private" to the wording:
+
+* if a subtype is a descendant of an untagged generic formal
+derived {or private} type, and the subtype is not an unconstrained array
+subtype, it is not considered indefinite and is considered to
+have a constrained partial view;
+
+But perhaps there is a better wording. An alternative would be:
+
+* if a subtype is a descendant of an untagged generic formal
+composite type, and the subtype is not an unconstrained array
+subtype, it is not considered indefinite and is considered to
+have a constrained partial view;
+
+since any interesting type would need to be composite. We don't need this to
+apply to a generic formal derived integer type.
+
+What wording should be used? Other suggestions welcome.
+
+Does anyone want to reconsider this AI? In the absence of a request for
+reconsideration, I'll just mention this topic in the minutes in an "after
+the meeting" box in the minutes.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, February 25, 2008  7:11 AM
+
+I guess I would go with "derived or private" since
+"generic composite" type is not a term we have
+used elsewhere, as far as I know.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, February 225 2008  1:33 PM
+
+You're right. In fact, the same AI uses "generic formal private or
+derived type" in the wording of 3.10.2(27.2/2). So that's what we should
+use.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent