CVS difference for ai12s/ai12-0095-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0095-1.txt

--- ai12s/ai12-0095-1.txt	2014/02/13 04:08:59	1.1
+++ ai12s/ai12-0095-1.txt	2014/07/12 03:29:16	1.2
@@ -3,6 +3,8 @@
 !standard 6.4.1(6.2/3)
 !standard 12.5.1(15)
 !class binding interpretation 14-02-12
+!status Corrigendum 2015 14-07-11
+!status ARG Approved 9-0-0  13-06-28
 !status work item 14-02-12
 !status received 13-12-04
 !priority Medium
@@ -11,9 +13,9 @@
 !subject Generic bodies assume-the-worst whether formal type have constrained partial views
 !summary
 
-Within a generic body, we assume-the-worst whether formal type have constrained partial views
-whether a subtype has a constrained partial view. In particular, we assume
-that untagged formal private and derived types have such a view.
+Within a generic body, we assume the worst whether or not a formal subtype
+has a constrained partial view. In particular, we assume that untagged formal
+private and derived types have such a view.
 
 !question
 
@@ -91,21 +93,21 @@
 
 Add an AARM Note after 3.10.2(27.2/3), 4.6(24.16/2), and 6.4.1(6.2/3):
 
-AARM Discussion: We assume-the-worst in a generic body whether a subtype has a
-constrained partial view; specifically, in a generic body a discriminated
-subtype is considered to have a constrained partial view if it is a
-descendant of an untagged generic formal private or derived type (see 12.5.1
-for the formal definition of this rule).
+AARM Discussion: We assume the worst in a generic body whether or not a formal
+subtype has a constrained partial view; specifically, in a generic body a
+discriminated subtype is considered to have a constrained partial view if it
+is a descendant of an untagged generic formal private or derived type (see
+12.5.1 for the formal definition of this rule).
 
-Modify 6.4.1(6.d/3):
+Modify AARM 6.4.1(6.d/3):
 
-This accessibility check (and its dynamic cousin as well) can only fail {if
-the master of the function call (which is defined in the Heart of Darkness,
+This accessibility check (and its dynamic cousin as well) can only fail if
+the {master of the function call (which is defined in the Heart of Darkness,
 or 3.10.2 if you prefer) is different than the master directly enclosing
-the call}[the function call is used to directly initialize a built-in-place
+the call}[function call is used to directly initialize a built-in-place
 object with a master different than that enclosing the call]. The
 {most likely}[only] place {where this will occur}[all of those conditions exist]
-is in the initializer of an allocator; in {almost}[all] other cases this check
+is in the initializer of an allocator; in {almost} all other cases this check
 will [always] pass.
 
 [Editor's note: The other semi-likely case where this could happen is when
@@ -116,8 +118,7 @@
 There are also cases involving a function call whose result is immediately
 returned (which can't fail a static check, and there shouldn't be a dynamic
 check in such cases) and access discriminants (which I didn't try to analyze).
-Should any of these be mentioned in this note, or should the last sentence
-be eliminated, or leave it as I've written it?]
+These weren't included in this note so that it didn't become a novella.]
 
 Add after 6.4.1(6.2/3):
 
@@ -151,10 +152,8 @@
 we define the term "known to be unconstrained" for this purpose. (This would
 be defined as the entire 3.10.2(27.2/3) bullet.) That would be an alternative to
 the chosen solution, but it was rejected as it would potentially be confused
-with "known to be constrained". [I've laid out this solution
-in more detail in the !appendix, in case it is preferred, perhaps using a
-different term. - Editor. Remove this note once we decide on the form of
-solution.]
+with "known to be constrained". [A detailed explanation of this solution can
+be found in the !appendix.]
 
 This change to the rules is incompatible for the type conversion and aliased
 parameter cases. In both cases, this is similar to the incompatibility
@@ -172,6 +171,39 @@
 the function = master of the return object is not the same as the master of the
 execution of the call. This note probaly predates the definition of "master of
 the function call" by AI05-0234-1; we've also corrected it.
+
+!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.
+For the purposes of determining within a generic body whether @i<D> is
+unconstrained in any partial view, a discriminated subtype is
+considered to have a constrained partial view if it is a descendant
+of an untagged generic formal private or derived type.>
+@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.>
+
+!corrigendum 6.4.1(6.2/3)
+
+@dinsa
+@xbullet<the subtype @i<F> shall be unconstrained, discriminated in its full
+view, and unconstrained in any partial view.>
+@dinst
+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 12.5.1(15)
+
+@dinsa
+For a generic formal type with an @fa<unknown_discriminant_part>, the actual
+may, but need not, have discriminants, and may be definite or indefinite.
+@dinst
+When enforcing Legality Rules, for the purposes of determining within a generic
+body whether a type is unconstrained in any partial view, a discriminated
+subtype is considered to have a constrained partial view if it is a descendant
+of an untagged generic formal private or derived type.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent