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

--- ai05s/ai05-0006-1.txt	2007/10/31 02:24:49	1.2
+++ ai05s/ai05-0006-1.txt	2007/12/13 04:39:33	1.3
@@ -1,6 +1,7 @@
-!standard  3.5.1(6)                                    07-10-29    AI05-0006-1/02
+!standard  3.5.1(6)                                    07-11-29    AI05-0006-1/03
 !standard  4.1.4(9)
-!class Amendment 05-10-24
+!class binding interpretation 07-11-10
+!status ARG Approved  8-0-1  06-11-10
 !status work item 06-03-17
 !status received 05-10-02
 !priority Low
@@ -9,9 +10,9 @@
 
 !summary
 
-(See proposal.)
+Define a nominal subtype for enumeration literals and attribute references.
 
-!problem
+!question
 
 Not all names have nominal subtypes defined. This causes issues when
 legality rules depend on the nominal subtype. Consider:
@@ -27,8 +28,10 @@
 
 Similar issues arise for everything that is defined as a name but does not
 define a nominal subtype; this includes at least a variety of attributes
-and enumeration literals.
+and enumeration literals. Should this be fixed? (Yes.)
 
+!recommendation
+
 Define nominal subtypes for names that lack a well-defined subtype,
 to be the base subtype or the first subtype, as appropriate.  
 This includes references to certain attributes and calls on
@@ -54,23 +57,23 @@
    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, for an attribute_reference that denotes a
-   function, unless explicitly specified otherwise, when its result
+   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 non-scalar, the result subtype is the first subtype of the
    type.
    
  AARM NOTE:
-     This is primarily a concern when an attribute_reference, or
+     The nominal subtype is primarily a concern when an attribute_reference, or
      a call on an attribute_reference, is used as the expression of a 
      case statement, due to the full coverage requirement based on 
-     the nominal subtype.  For non-discrete cases, we define the
-     nominal subtype mainly for completeness.  Implementations may
+     the nominal subtype. For non-discrete cases, we define the
+     nominal subtype mainly for completeness. Implementations may
      specify otherwise for implementation-defined attribute functions.
      
  AARM TO BE HONEST:
      We don't worry about the fact that "base subtype" or "first subtype"
-     is not explicitly defined for the universal types.  Since it is
+     is not explicitly defined for the universal types. Since it is
      not possible to constrain a universal numeric type, all subtypes
      are unconstrained, and hence can be considered base subtypes.
      Similarly, since it is not possible to define a subtype of the
@@ -84,15 +87,15 @@
 !discussion
 
 Under certain circumstances, it is useful to use an attribute reference
-or an enumeration literal as a case expression.  In these situations,
+or an enumeration literal as a case expression. In these situations,
 it is necessary to know what is the nominal subtype of the expression,
 since that determines what choices are permitted on the various
-case alternatives.  In the !problem we have an example that came up
+case alternatives. In the !question we have an example that came up
 in actual usage.
 
 Nominal subtypes are also relevant in other contexts, so it seems useful
 to make sure that all names that denote values or objects have 
-well-defined nominal subtypes.  Here we follow the lead from the existing
+well-defined nominal subtypes. Here we follow the lead from the existing
 language-defined attribute functions such as 'Input, which return
 the base subtype or the first subtype, depending on whether or not
 the result type is scalar, to choose the same rule in general.
@@ -109,8 +112,43 @@
 of staticness.
 
 !example
+
+(See question.)
+
+!corrigendum 3.5.1(6)
 
-(See problem.)
+@drepl
+Each @fa<enumeration_literal_specification> is the explicit declaration
+of the corresponding @i<enumeration literal>: it declares
+a parameterless function,
+whose defining name is the @fa<defining_identifier>
+or @fa<defining_character_literal>, and whose result type
+is the enumeration type.
+@dby
+Each @fa<enumeration_literal_specification> is the explicit declaration
+of the corresponding @i<enumeration literal>: it declares
+a parameterless function,
+whose defining name is the @fa<defining_identifier>
+or @fa<defining_character_literal>, and whose result subtype
+is the base subtype of the enumeration type.
+
+!corrigendum 4.1.4(9)
+
+@drepl
+An @fa<attribute_reference> denotes a
+value, an object, a subprogram, or some
+other kind of program entity.
+@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 non-scalar, the result subtype is the first subtype of the
+type.
 
 !ACATS test