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

--- ai05s/ai05-0006-1.txt	2006/03/18 06:09:23	1.1
+++ ai05s/ai05-0006-1.txt	2007/10/31 02:24:49	1.2
@@ -1,4 +1,5 @@
-!standard  3.5(13)                                    06-03-17    AI05-0006-1/01
+!standard  3.5.1(6)                                    07-10-29    AI05-0006-1/02
+!standard  4.1.4(9)
 !class Amendment 05-10-24
 !status work item 06-03-17
 !status received 05-10-02
@@ -28,24 +29,92 @@
 define a nominal subtype; this includes at least a variety of attributes
 and enumeration literals.
 
-!proposal
+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
+enumeration literals and attribute functions.
 
-Define nominal subtypes for these things (and make sure that there aren't
-other things that also need subtypes defined).
-
 !wording
+
+Modify 3.5.1(6) as follows:
 
-(TBD.)
+   Each enumeration_literal_specification is the explicit declaration
+   of the corresponding enumeration literal: it declares a
+   parameterless function, whose defining name is the
+   defining_identifier or defining_character_literal, and whose result
+   [type is] {subtype is the base subtype of} the enumeration type.
+   
+ AARM NOTE:
+     The result subtype is primarily a concern when an enumeration
+     literal is used as the expression of a case statement, due to
+     the full coverage requirement based on the nominal subtype.
+
+At the end of 4.1.4(9) add:
+
+   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
+   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
+     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
+     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
+     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
+     universal access type, all subtypes are considered first subtypes.
+     The wording above could be altered to bypass this issue, but it
+     doesn't seem necessary, since universal integer is handled
+     specially in the rules for case expression full coverage, and
+     we don't allow user-defined functions for attribute functions
+     whose result type is universal.
 
 !discussion
 
+Under certain circumstances, it is useful to use an attribute reference
+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
+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
+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.
+For attribute functions, we allow for the possibility that the
+result subtype is specified explicitly to be other than the
+base or first subtype.
+
+We considered defining this only for static expressions, since in
+a case expression, the base subtype is already specified when the
+expression is non-static.  But it seemed odd to have a well-defined
+nominal subtype only for static expressions, since the concept of
+a nominal subtype has little or nothing to do with staticness.
+Hence, we provided a definition for nominal subtype independent
+of staticness.
+
 !example
 
 (See problem.)
 
 !ACATS test
 
-An ACATS C-Test should be created to test these cases.
+An ACATS C-Test (or B-Test) should be created to test these cases.
 
 !appendix
 
@@ -73,5 +142,42 @@
 is no defined nominal subtype.
 
 Any thoughts?
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, October 29, 2007  2:53 PM
+
+Here is the first "real" version of AI05-6 [version /02 - ED.],
+on defining nominal subtypes for those names
+that don't currently have one.  No real
+shocker.  We suggest base subtype if scalar,
+and first subtype otherwise.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Monday, October 29, 2007  4:26 PM
+
+> Modify 3.5.1(6) as follows:
+> 
+>    Each enumeration_literal_specification is the explicit declaration
+>    of the corresponding enumeration literal: it declares a
+>    parameterless function, whose defining name is the
+>    defining_identifier or defining_character_literal, and whose result
+>    [type is] {subtype is the base subtype of} the enumeration type.
+>    
+>  AARM NOTE:
+>      This is primarily a concern ...
+
+Minor wording nitpick on the AARM notes: It's not crystal clear what "This"
+refers to.  I suggest, "The result subtype".
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, October 29, 2007  4:42 PM
+
+Good point.
 
 ****************************************************************