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

--- ai05s/ai05-0006-1.txt	2008/05/10 05:14:33	1.4
+++ ai05s/ai05-0006-1.txt	2008/05/22 05:23:02	1.5
@@ -1,6 +1,7 @@
-!standard  3.5.1(6)                                    08-04-09    AI05-0006-1/04
+!standard  3.5.1(6)                                    08-05-21    AI05-0006-1/05
 !standard  4.1.4(9)
 !class binding interpretation 07-11-10
+!status work item 08-05-21
 !status ARG Approved  8-0-1  06-11-10
 !status work item 06-03-17
 !status received 05-10-02
@@ -56,12 +57,15 @@
 
    For an attribute_reference that denotes a value or an object, if
    its type is scalar, then its nominal subtype is the base subtype of
-   the type; otherwise, its nominal subtype is the first subtype of
-   the type. Similarly, unless explicitly specified otherwise, for an
-   attribute_reference that denotes a function, when its result
-   type is scalar, its result subtype is the base subtype of the type,
-   and when nonscalar, the result subtype is the first subtype of the
-   type.
+   the type; if its type is tagged, its nominal subtype is the first subtype of
+   the type; otherwise, its nominal subtype is a subtype of the type
+   without any constraint or null_exclusion. Similarly, unless explicitly
+   specified otherwise, for an attribute_reference that denotes a function,
+   when its result type is scalar, its result subtype is the base subtype of
+   the type, when its result type is tagged, the result subtype is the first
+   subtype of the type, and when the result type is some other type,
+   the result subtype is a subtype of the type without any constraint or
+   null_exclusion.
    
  AARM NOTE:
      The nominal subtype is primarily a concern when an attribute_reference, or
@@ -70,6 +74,9 @@
      the nominal subtype. For non-discrete cases, we define the
      nominal subtype mainly for completeness. Implementations may
      specify otherwise for implementation-defined attribute functions.
+
+     The rule is written to match the meaning of the italicized T in the
+     definition of attributes such as Input; see 4.5.1.
      
  AARM TO BE HONEST:
      We don't worry about the fact that "base subtype" or "first subtype"
@@ -141,14 +148,17 @@
 @dby
 An @fa<attribute_reference> denotes a value, an object,
 a subprogram, or some other kind of program entity. For an
-@fa<attribute_reference> that denotes a value or an object, if
-its type is scalar, then its nominal subtype is the base subtype of
-the type; otherwise, its nominal subtype is the first subtype of
-the type. Similarly, unless explicitly specified otherwise, for an
-@fa<attribute_reference> that denotes a function, when its result
-type is scalar, its result subtype is the base subtype of the type,
-and when nonscalar, the result subtype is the first subtype of the
-type.
+@fa<attribute_reference> that denotes a value or an object,
+if its type is scalar, then its nominal subtype is the base subtype of
+the type; if its type is tagged, its nominal subtype is the first subtype of
+the type; otherwise, its nominal subtype is a subtype of the type
+without any constraint or @fa<null_exclusion>. Similarly, unless explicitly
+specified otherwise, for an @fa<attribute_reference> that denotes a function,
+when its result type is scalar, its result subtype is the base subtype of
+the type, when its result type is tagged, the result subtype is the first
+subtype of the type, and when the result type is some other type,
+the result subtype is a subtype of the type without any constraint or
+@fa<null_exclusion>.
 
 !ACATS test
 
@@ -217,5 +227,54 @@
 Date: Monday, October 29, 2007  4:42 PM
 
 Good point.
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Monday, May 12, 2008  12:42 PM
+
+The rules appended to 4.1.4(9) are strangely inconsistent with 4.5.1(3.c/2-3.i/2).
+4.5.1(3.i/2) says that italicized T in the definition of Input for a 
+constrained array type is an unconstrained array subtype (and 
+similarly for null exclusions).  But the new rule says that the 
+nominal subtype is the constrained array type.  This doesn't seem right.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, May 15, 2008  11:28 PM
+
+One could argue that Input is "specified otherwise", but that seems pretty
+weak, considering that the rules are only really given in the AARM. And the
+rules of 4.5.1 are intended to be general, making one wonder why they don't
+apply to attributes consistently.
+
+So I think we need a fix of some sort.
+
+****************************************************************
+
+From: Ed Schonberg
+Date: Monday, May 19, 2008  1:39 PM
+
+I agree that there is a problem with 4.5.1. It interesting that the
+discussion of the AI mentions 'Input explicitly as an example we might
+follow, when Pascal notes that this is precisely the case that conflicts
+with the current wording. 
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, May 19, 2008  2:27 PM
+
+I agree with Pascal that there is an inconsistency.
+I agree with Ed that we shouldn't try to rush a fix for this as it is a
+very unimportant AI, and it is better to get it right the first time
+we send it to WG-9.
+
+Presuming we accept what 4.5.1(3.c ff) says, we should make 4.1.4
+consistent with it, saying that for tagged types you get the first
+subtype, and for other non-scalar types you get the type without any
+constraint or null exclusion.  But I suspect we want to get that wording
+formalized and vetted, rather than rushed out in the next day or two.
 
 ****************************************************************