!standard  3.5.1(6)                                    08-07-07    AI05-0006-1/06
!standard  4.1.4(9)
!class binding interpretation 07-11-10
!status WG9 Approved 08-10-31
!status ARG Approved  8-0-0  08-06-21
!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
!priority Low
!difficulty Easy
!subject Nominal subtypes for all names

!summary

Define a nominal subtype for enumeration literals and attribute references.

!question

Not all names have nominal subtypes defined. This causes issues when
legality rules depend on the nominal subtype. Consider:

     subtype S is Integer range 1 .. 10;
     case S'Last is
       when 0 =>  -- OK?
         ...

Since the nominal subtype of S'Last isn't defined, we can't determine whether
0 is allowed as a discrete choice, since that depends on the nominal subtype
of the case expression.

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. Should this be fixed? (Yes.)

!recommendation

Define nominal subtypes for names that lack a well-defined subtype,
to be an appropriate subtype. This includes references to certain attributes
and calls on enumeration literals and attribute functions.

!wording

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:
     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; 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
     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.

     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"
     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.
     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 !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
language-defined attribute functions such as 'Input, which return
the italicized T subtype (see AARM 4.5.1(3.c-3.i)).
For attribute functions, we allow for the possibility that the
result subtype is specified explicitly to be other than the
italicized T subtype specified by this rule.

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 question.)

!corrigendum 3.5.1(6)

@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; 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

An ACATS C-Test (or B-Test) should be created to test these cases.

!appendix

From: Tucker Taft
Date: Sunday, October  2, 2005  8:08 PM

I bumped into an interesting situation recently,

     case S'Last is
       when 0 =>  -- error: choice shall cover only values of
                  --        the nominal subtype
         ...

Our compiler had decided the nominal subtype of S'Last
was S, and zero wasn't a value of the subtype S.
But there isn't any definition of what is the
nominal subtype of attributes.  If S turns out to
be a null subtype, then clearly neither S'Last nor
S'First will be a value of subtype S.  So I came to
the conclusion that the nominal subtype of an
attribute like S'Last or S'First would be S'Base.
But it really ought to say that somewhere.  Similar
questions arise for enumeration literals and other
things that happen to be "Name"s but for which there
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.

****************************************************************

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.

****************************************************************