CVS difference for 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