Version 1.1 of ai12s/ai12-0206-1.txt

Unformatted version of ai12s/ai12-0206-1.txt version 1.1
Other versions for file ai12s/ai12-0206-1.txt

!standard 13.1.1(18.2/4)          16-11-14 AI12-0206-1/01
!standard 13.1.1(18.3/4)
!standard 13.1.1(18.6/4)
!class binding interpretation 16-11-14
!status Amendment 1-2012 16-11-14
!status work item 16-11-14
!status received 16-10-09
!priority Medium
!difficulty Easy
!qualifier Omission
!subject Nonoverridable should allow arbitrary kinds of aspects
!summary
Nonoverridable aspects can be any kind of aspect, not just names.
!question
It would be convinient to declare Max_Entry_Queue_Length as a nonoverridable aspect, as we don't want derived types to be able to change it (see AI12-0164-1). But a nonoverridable aspect must be a name. Can this be changed? (Yes.)
!recommendation
(See Summary.)
!wording
[Editor's note: This AI's text has been prematurely added to the draft Standard in order that AI12-0164-1 is fully defined in the draft. The ACATS documents have also been updated; be sure to apply any changes in both places.]
Replace 13.1.1(18.2-18.3/4):
Certain type-related aspects are defined to be nonoverridable; all such aspects are specified using an aspect_definition that is a name.
If a nonoverridable aspect is directly specified for a type T, then any explicit specification of that aspect for any other descendant of T shall be confirming; that is, the specified name shall match the inherited aspect, meaning that the specified name shall denote the same declarations as would the inherited name.
with:
Certain type-related aspects are defined to be nonoverridable.
If a nonoverridable aspect is directly specified for a type T, then any explicit specification of that aspect for any other descendant of T shall be confirming. In the case of an aspect whose value is a name, this means that the specified name shall match the inherited aspect and therefore denote the same declarations as would the inherited name.
[Editor's note: Steve had the second sentence as Redundant, but I think this is the definition of "confirming" for a name; 13.1 doesn't clearly cover that case. (That's why it was here in the first place.)]
In 13.1.1(18.6/4), replace:
"and Variable_Indexing"
with:
"Variable_Indexing, and Max_Entry_Queue_Length"
This change is tied to AI12-0164-1.
!discussion
There's no particular reason for this concept to be tied to name-valued aspects. Thus we extend it to work for all kinds of aspects for which "confirming" is well-defined.
!corrigendum 13.1.1(18.2/4)
Replace the paragraph:
Certain type-related aspects are defined to be nonoverridable; all such aspects are specified using an aspect_definition that is a name.
by:
Certain type-related aspects are defined to be nonoverridable.
!corrigendum 13.1.1(18.3/4)
Replace the paragraph:
If a nonoverridable aspect is directly specified for a type T, then any explicit specification of that aspect for any other descendant of T shall be confirming; that is, the specified name shall match the inherited aspect, meaning that the specified name shall denote the same declarations as would the inherited name.
by:
If a nonoverridable aspect is directly specified for a type T, then any explicit specification of that aspect for any other descendant of T shall be confirming. In the case of an aspect whose value is a name, this means that the specified name shall match the inherited aspect and therefore denote the same declarations as would the inherited name.
!corrigendum 13.1.1(18.6/4)
Replace the paragraph:
The Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing, and Variable_Indexing aspects are nonoverridable.
by:
The Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing, Variable_Indexing, and Max_Entry_Queue_Length aspects are nonoverridable.
!ASIS
No ASIS effect.
!ACATS test
No separate ACATS test is needed; this should be tested in the context of AI12-0164-1.
!appendix

From: Steve Baird
Sent: Sunday, October 9, 2016  4:50 PM

AI12-0164 is about the Integer-valued Max_Extry_Queue_Length aspect.

We want this aspect to be nonoverridable, but there is some current RM wording
which assumes that the value of a nonoverridable aspect is always a name.

The following is an attempt to generalize this existing wording in order to
allow non-name-valued nonoverridable aspects.


====

Replace 18.2-18.3

   Certain type-related aspects are defined to be nonoverridable; all
   such aspects are specified using an aspect_definition that is a name.

   If a nonoverridable aspect is directly specified for a type T, then
   any explicit specification of that aspect for any other descendant of
   T shall be confirming; that is, the specified name shall match the
   inherited aspect, meaning that the specified name shall denote the
   same declarations as would the inherited name.

with

   Certain type-related aspects are defined to be nonoverridable.

   If a nonoverridable aspect is directly specified for a type T,
   then any explicit specification of that aspect for any other
   descendant of T shall be confirming. [Redundant: In the case of
   an aspect whose value is a name, this means that the specified name
   shall match the inherited aspect and therefore denote the same
   declarations as would the inherited name.]

In 18.6, replace

    "and Variable_Indexing"

with

    "Variable_Indexing, and Max_Entry_Queue_Length"

This 18.6 change is tied to AI12-0164 .

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

From: Tucker Taft
Sent: Sunday, October 9, 9:55 PM

Thanks, Steve.  Looks good to me!

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

Questions? Ask the ACAA Technical Agent