Version 1.5 of ai05s/ai05-0006-1.txt
!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
!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 => --
...
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 the base subtype or the first subtype, as appropriate.
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" 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 !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 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 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