!standard 7.5(4) 05-02-26 AI95-00411/02
!standard 3.9.4(1)
!class amendment 05-02-07
!status Amendment 200Y 05-02-26
!status ARG Approved 10-0-0 05-02-12
!status work item 05-02-07
!status received 05-02-07
!priority High
!difficulty Easy
!subject Predefined equality for types derived from interfaces
!summary
No additional wording is required to ensure that the "=" operator
works as expected for nonlimited types whose parent type is an
interface.
!problem
There is some concern that we have forgotten about the "=" operator
and how it relates to nonlimited interfaces. In particular,
unless declared explicitly as abstract, the primitive equality
operators for an interface will be non-abstract. In fact,
they will be the only non-abstract primitive functions, since
any others are necessarily user-declared, and will necessarily
be declared as abstract (since only procedures can be declared "null").
!proposal
No additional wording is needed, though this is not obvious,
and we will need to double check the sections indicated in the
discussion after the final revisions to be sure everything
still works.
It would be useful to mention in a note when talking about
interfaces that they have non-abstract equality operators,
if nonlimited.
There also is a wording error in 7.5 - limited interfaces are not
included in the list of limited things. (While a declared limited interface
includes the word "limited" and thus is covered by the existing wording,
task and protected interfaces are not.)
!wording
Add a note in the new 3.9.4 proposed by AI-251 and AI-345:
NOTE 1: Nonlimited interface types have predefined nonabstract equality
operators. These may be overridden with user-defined abstract
equality operators. Such operators will then require
an explicit overriding for any nonabstract descendant of the
interface.
Add after 7.5(4):
* a limited interface;
!discussion
Here are some relevant paragraphs, which combine to make "="
work properly for types derived from interfaces. I believe
we need
3.4(16):
For each predefined operator of the parent type, there is a corresponding
predefined operator of the derived type.
3.4(17):
Primitive user-defined equality operators of the parent type are
also inherited by the derived type, except when the derived type is
a nonlimited record extension, and the inherited operator would have
a profile that is type conformant with the profile of the
corresponding predefined equality operator; in this case, the
user-defined equality operator is not inherited, but is rather
incorporated into the implementation of the predefined equality
operator of the record extension (see 4.5.2).
3.9.4(7/2):
All user-defined primitive subprograms of an interface type shall be
abstract subprograms or null procedures.
4.5.2(6-7):
The equality operators are predefined for every specific type T that
is not limited, and not an anonymous access type, with the following
specifications:
function "=" (Left, Right : T) return Boolean
function "/="(Left, Right : T) return Boolean
4.5.2(14):
For a type extension, predefined equality is defined in terms of the
primitive [(possibly user-defined)] equals operator of the parent type and
of any tagged components of the extension part, and predefined equality for
any other components not inherited from the parent type.
4.5.2(22):
If there are no components, the result is defined to be True;
4.5.2(25):
The predefined "/=" operator gives the complementary result to the
predefined "=" operator.
7.5(3-8):
A type is limited if it is a descendant of one of the following:
* a type with the reserved word limited in its definition;
* a task or protected type;
* a composite type with a limited component.
Otherwise, the type is nonlimited.
[There are no predefined equality operators for a limited type.]
!comment !corrigendum 3.9.4(1) We've done this in the Conflict text without
!comment a formal reference (so we don't have to allow 4-way conflicts).
!corrigendum 7.5(4)
@dinsa
@xbullet in its definition;>
@dinst
@xbullet
!ACATS test
!appendix
*************************************************************