4.5.2 Relational Operators and Membership Tests

Ramification: The equality operators are not defined for every nonlimited type — see below for the exact rule. 

Reason: {AI95-00230-01} The part of the rule for untagged types is stated in a way that ensures that operands like a string literal are still legal as operands of a membership test.

{AI95-00251-01} The significance of “is convertible to” is that we allow the simple_expression to be of any class-wide type that could be converted to the tested type, not just the one rooted at the tested type. This includes any class-wide type that covers the tested type, along with class-wide interfaces in some cases. 

Ramification: Untagged types covered by the tagged class-wide type are not permitted. Such types can exist if they are descendants of a private type whose full type is tagged. This rule is intended to avoid confusion since such derivatives don't have their “own” tag, and hence are indistinguishable from one another at run time once converted to a covering class-wide type.

Reason: The first sentence prevents compatibility problems by ensuring that these operators are not used for named access types. Also, universal access types do not count for the purposes of this rule. Otherwise, equality expressions like (X = null) would be ambiguous for normal access types.

The rest of the rule makes it possible to call (including a dispatching call) user-defined "=" operators for anonymous access-to-object types (they'd be hidden otherwise), and to write user-defined "=" operations for anonymous access types (by making it possible to see the universal operator using the Standard prefix). 

Ramification: We don't need a similar rule for anonymous access-to-subprogram types because they can't be primitive for any type. Note that any non-primitive user-defined equality operators still are hidden by the universal operators; they'll have to be called with a package prefix, but they are likely to be very uncommon. 

Reason: We don't want to allow completely arbitrary comparisons, as we don't want to insist that all access types are represented in ways that are convertible to one another. For instance, a compiler could use completely separate address spaces or incompatible representations. Instead, we allow compares if there exists an access parameter to which both operands could be converted. Since the user could write such an subprogram, and any reasonable meaning for "=" would allow using it in such a subprogram, this doesn't impose any further restrictions on Ada implementations. 

Ramification: For floating point types, the results of comparing nearly equal values depends on the accuracy of the implementation (see G.2.1, “Model of Floating Point Arithmetic” for implementations that support the Numerics Annex). 

Implementation Note: On a machine with signed zeros, if the generated code generates both plus zero and minus zero, plus and minus zero must be equal by the predefined equality operators.

Reason: This allows each Access attribute_reference for a subprogram to designate a distinct “wrapper” subprogram if necessary to support an indirect call. 

Ramification: Two values of a type extension are not equal if there is a variant_part in the extension part and the two values have different variants present. This is a ramification of the requirement that a discriminant governing such a variant_part has to be a “new” discriminant, and so has to be equal in the two values for the values to be equal. Note that variant_parts in the parent part need not match if the primitive equals operator for the parent type considers them equal.

{AI95-00349-01} The full type extension's operation is used for a private extension. This follows as only full types have parent types; the type specified in a private extension is an ancestor, but not necessarily the parent type. For instance, in: 

the parent type is Pak1.Typ2, not Pak1.Typ1, and the equality operator of Pak1.Typ2 is used to create predefined equality for Typ3. 

Discussion: Ada 83 seems to omit this part of the definition, though it is used in array type conversions. See 4.6. 

Reason: This asymmetry between tagged and untagged components is necessary to preserve upward compatibility and corresponds with the corresponding situation with generics, where the predefined operations “reemerge” in a generic for untagged types, but do not for tagged types. Also, only tagged types support user-defined assignment (see 7.6), so only tagged types can fully handle levels of indirection in the implementation of the type. For untagged types, one reason for a user-defined equals operator might be to allow values with different bounds or discriminants to compare equal in certain cases. When such values are matching components, the bounds or discriminants will necessarily match anyway if the discriminants of the enclosing values match. 

Ramification: Two null arrays of the same type are always equal; two null records of the same type are always equal.

Note that if a composite object has a component of a floating point type, and the floating point type has both a plus and minus zero, which are considered equal by the predefined equality, then a block compare cannot be used for the predefined composite equality. Of course, with user-defined equals operators for tagged components, a block compare breaks down anyway, so this is not the only special case that requires component-by-component comparisons. On a one's complement machine, a similar situation might occur for integer types, since one's complement machines typically have both a plus and minus (integer) zero.

To be honest: {AI95-00230-01} For a component with an anonymous access type, “predefined equality” is that defined for the universal_access type (anonymous access types have no equality operators of their own).

For a component with a tagged type T, “the primitive equals operator” is the one with two parameters of T which returns Boolean. We're not talking about some random other primitive function named "=". 

Ramification: Furthermore, if the user defines an "=" operator that returns Boolean, then a "/=" operator is implicitly declared in terms of the user-defined "=" operator so as to give the complementary result. See 6.6.

Ramification: The scalar membership test only does a range check. It does not perform any other check, such as whether a value falls in a “hole” of a “holey” enumeration type. The Pos attribute function can be used for that purpose.

Even though Standard.Float is an unconstrained subtype, the test “X in Float” will still return False (presuming the evaluation of X does not raise Constraint_Error) when X is outside Float'Range. 

Ramification: Note that the tag is not checked if the simple_expression is of a specific type. 

Ramification: If any language-defined types are implemented with a user-defined "=" operator, then either the full type must be tagged, or the compiler must use “magic” to implement equality for this type. A normal user-defined "=" operator for an untagged type does not meet this requirement.

{extensions to Ada 83} Membership tests can be used to test the tag of a class-wide value.

Predefined equality for a composite type is defined in terms of the primitive equals operator for tagged components or the parent part. 

The term “membership test” refers to the relation "X in S" rather to simply the reserved word in or not in.

We use the term “equality operator” to refer to both the = (equals) and /= (not equals) operators. Ada 83 referred to = as the equality operator, and /= as the inequality operator. The new wording is more consistent with the ISO 10646 name for "=" (equals sign) and provides a category similar to “ordering operator” to refer to both = and /=.

We have changed the term “catenate” to “concatenate”. 

{AI95-00230-01} {AI95-00420-01} {extensions to Ada 95} The universal_access equality operators are new. They provide equality operations (most importantly, testing against null) for anonymous access types. 

{8652/0016} {AI95-00123-01} Corrigendum: Wording was added to clarify that the order of calls (and whether the calls are made at all) on "=" for components is unspecified. Also clarified that "=" must compose properly for language-defined types.

{AI95-00251-01} Memberships were adjusted to allow interfaces which don't cover the tested type, in order to be consistent with type conversions.