CVS difference for ais/ai-00123.txt
--- ais/ai-00123.txt 2000/07/15 02:29:57 1.7
+++ ais/ai-00123.txt 2000/08/01 05:39:33 1.8
@@ -1,4 +1,4 @@
-!standard 04.05.02 (24) 00-04-11 AI95-00123/10
+!standard 04.05.02 (24) 00-07-31 AI95-00123/11
!standard 04.05.02 (32)
!class binding interpretation 96-07-23
!status Corrigendum 2000 99-07-28
@@ -20,7 +20,7 @@
type, or a generic actual type.
For any composite type, the order in which "=" is called for components
-is not defined by the language. Furthermore, if the result can be
+is not defined by the language. Furthermore, if the result can be
determined before calling "=" on some components, the language does not
define whether "=" is called on those components.
@@ -43,7 +43,7 @@
This would seem to imply that the composability of these "=" operators
depends on whether the implementation chooses to implement them as
-tagged types, by 4.5.2(14-25):
+tagged types, by 4.5.2(14-15):
For a type extension, predefined equality is defined in terms of the
primitive (possibly user-defined) equals operator of the parent type and of
@@ -104,7 +104,7 @@
comparing the extension parts.
Non-composability means that the predefined equality is called for T,
-despite the fact that T has a user-defined equality operator. Of
+despite the fact that T has a user-defined equality operator. Of
course, if there is no user-defined equality, then equality always
composes properly.
@@ -112,7 +112,7 @@
(visibly) tagged.
For a private type, if the underlying type is tagged, or if there is no
-user-defined equality, then equality composes. Otherwise, it does not.
+user-defined equality, then equality composes. Otherwise, it does not.
(Here, "underlying type" means the full type, or if that comes from a
private type, then the underlying type of *that* type, and so on.)
@@ -122,25 +122,25 @@
normal bit-wise equality).
It is important that the composability of "=" for these types be defined
-by the language. We choose to make them composable. An implementation
-can achieve this by making the full type tagged. Alternatively, the
+by the language. We choose to make them composable. An implementation
+can achieve this by making the full type tagged. Alternatively, the
implementation could simply use the predefined "=" for these types.
(Alternatively, an implementation could treat these types specially,
-making them untagged, but with composable equality. However, this would
+making them untagged, but with composable equality. However, this would
add some complexity to the compiler.)
Here is an analysis of implementation concerns for each type in
question:
- System.Address: The intent is for this type to directly represent
- a hardware address. Therefore, it is probably not feasible to
- implement it as a tagged type. The simplest implementation of
- equality of Addresses is thus the normal bit-wise equality. This
+ a hardware address. Therefore, it is probably not feasible to
+ implement it as a tagged type. The simplest implementation of
+ equality of Addresses is thus the normal bit-wise equality. This
is what most users would expect, anyway.
On certain segmented architectures, it is possible for two
- different addresses to point to the same location. The same thing
- can happen due to memory mapping, on many machines. Such
+ different addresses to point to the same location. The same thing
+ can happen due to memory mapping, on many machines. Such
addresses will typically compare unequal, despite the fact that
they point to the same location.
@@ -151,13 +151,13 @@
- Ada.Strings.Bounded.Generic_Bounded_Length.Bounded_String: Two
reasonable implementations are: (1) Set the unused characters to
some particular character, and use bit-wise equality, and (2) use
- a tagged type with a user-defined equality. Either way, equality
- will compose. This is, admittedly, a slight implementation
+ a tagged type with a user-defined equality. Either way, equality
+ will compose. This is, admittedly, a slight implementation
burden, because it rules out an untagged record with user-defined
equality.
- Ada.Strings.Unbounded.Unbounded_String: A tagged (controlled) type
- will normally be necessary anyway, for storage reclamation. In a
+ will normally be necessary anyway, for storage reclamation. In a
garbage-collected implementation, a tagged type is not strictly
necessary, but we choose to require composability anyway.
@@ -168,21 +168,21 @@
- Ada.Task_Identification.Task_ID: This will typically be a
pointer-to-TCB of some sort (access-to-TCB, or
- index-into-table-of-TCB's). In any case, bit-wise equality will
+ index-into-table-of-TCB's). In any case, bit-wise equality will
work, so equality will compose.
As to the second question, the standard clearly does not define any order of
calling "=" on components, nor does it say whether the results are
-combined with "and" or "and then". Equality operators with side effects
+combined with "and" or "and then". Equality operators with side effects
are questionable in any case, so we allow implementations freedom to do
-what is most convenient and/or most efficient. Consider equality of a
+what is most convenient and/or most efficient. Consider equality of a
variant record: The implementation might first check that the
discriminants are equal, and if not, skip the component-by-component
-comparison. Alternatively, the implementation might first compare the
-common elements, and *then* check the discriminants. A third
+comparison. Alternatively, the implementation might first compare the
+common elements, and *then* check the discriminants. A third
possibility is to first compare some portions with a bit-wise equality,
and then (conditionally) call user-defined equality operators on the
-other components. All of these implementations are valid.
+other components. All of these implementations are valid.
!corrigendum 4.05.02(24)
@@ -192,7 +192,7 @@
equals for any matching untagged components.>
@dinst
For any composite type, the order in which "=" is called for components is
-not defined by the language. Furthermore, if the result can be determined
+not defined by the language. Furthermore, if the result can be determined
before calling "=" on some components, the language does not define whether
"=" is called on those components.
@@ -204,8 +204,9 @@
@dinst
@i<@s8<Implementation Requirements>>@hr
For all nonlimited types declared in language-defined packages, the "="
-operator of the type shall behave as if it were the predefined equality operator
-for the purposes of composite equality and generic formal type equality.
+and "/=" operators of the type shall behave as if they were the predefined
+equality operators for the purposes of the equality of composite types and
+generic formal types.
!ACATS test
Questions? Ask the ACAA Technical Agent