!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)

@drepl
Certain type-related aspects are defined to be @i<nonoverridable>; all such
aspects are specified using an @fa<aspect_definition> that is a @fa<name>.
@dby
Certain type-related aspects are defined to be @i<nonoverridable>.

!corrigendum 13.1.1(18.3/4)

@drepl
If a nonoverridable aspect is directly specified for a type @i<T>, then any
explicit specification of that aspect for any other descendant of @i<T>
shall be @i<confirming>; that is, the specified @fa<name> shall @i<match>
the inherited aspect, meaning that the specified @fa<name> shall denote the
same declarations as would the inherited @fa<name>.
@dby
If a nonoverridable aspect is directly specified for a type @i<T>, then any
explicit specification of that aspect for any other descendant of @i<T>
shall be @i<confirming>. In the case of an aspect whose value is a @fa<name>,
this means that the specified @fa<name> shall @i<match> the inherited aspect
and therefore denote the same declarations as would the inherited
@fa<name>.

!corrigendum 13.1.1(18.6/4)

@drepl
The Default_Iterator, Iterator_Element, Implicit_Dereference,
Constant_Indexing, and Variable_Indexing aspects are nonoverridable.
@dby
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!

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