Version 1.6 of ai05s/ai05-0006-1.txt

Unformatted version of ai05s/ai05-0006-1.txt version 1.6
Other versions for file ai05s/ai05-0006-1.txt

!standard 3.5.1(6)          08-07-07 AI05-0006-1/06
!standard 4.1.4(9)
!class binding interpretation 07-11-10
!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)
Replace the paragraph:
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 the enumeration type.
by:
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 subtype is the base subtype of the enumeration type.
!corrigendum 4.1.4(9)
Replace the paragraph:
An attribute_reference denotes a value, an object, a subprogram, or some other kind of program entity.
by:
An attribute_reference denotes a value, an object, a subprogram, or some other kind of program entity. 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.
!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.

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

Questions? Ask the ACAA Technical Agent