CVS difference for ai05s/ai05-0123-1.txt

Differences between 1.10 and version 1.11
Log of other versions for file ai05s/ai05-0123-1.txt

--- ai05s/ai05-0123-1.txt	2009/07/11 03:06:22	1.10
+++ ai05s/ai05-0123-1.txt	2009/10/15 04:20:17	1.11
@@ -1,4 +1,4 @@
-!standard  4.5.2(9.7/2)                               09-06-29   AI05-0123-1/06
+!standard  4.5.2(9.7/2)                               09-10-12   AI05-0123-1/07
 !standard  4.5.2(14)
 !standard  4.5.2(15)
 !standard  4.5.2(24)
@@ -48,18 +48,14 @@
 Add after 4.5.2(9.7/2):
 
   The explicit declaration of a primitive equality operator of an
-  untagged record type shall occur before the type is frozen.
-  If the untagged record type has a nonlimited partial view, then the
-  declaration shall occur in the visible part of the enclosing package.
-  In addition to the places where Legality Rules normally apply (see 12.3),
-  this rule applies also in the private part of an instance of a generic unit.
-
-  AARM Note:
-  The phrase "equality operator" as used here refers only to a
-  function whose profile is type conformant with that of the
-  predefined equality operator for the untagged record type.
+  untagged record type, if its profile is type conformant
+  with that of the corresponding predefined equality operator,
+  shall occur before the type is frozen. If the untagged record type
+  has a nonlimited partial view, then the declaration shall occur in
+  the visible part of the enclosing package. In addition to the places
+  where Legality Rules normally apply (see 12.3), this rule applies also
+  in the private part of an instance of a generic unit.
 
-
 Replace 4.5.2(14):
 
   For a type extension, predefined equality is defined in terms of the
@@ -71,7 +67,7 @@
 
   For a type extension, predefined equality is defined in terms of the
   primitive [(possibly user-defined)] equals operator for the parent type
-  and for any components of a record type in the extension part, and
+  and for any components that have a record type in the extension part, and
   predefined equality for any other components not inherited from the
   parent type.
 
@@ -143,8 +139,8 @@
 
 Note that arrays with a component type that is a record with a user-defined "="
 will compose "=" correctly (the predefined array "=" will use the user-defined
-"=" on the components); this just means that arrays with user-defined "=" will
-not have that "=" compose. (It is likely that the "=" exists simply because the
+"=" on the components); this just means that in the case of arrays with user-defined
+"=", the "=" will not compose. (It is likely that the "=" exists simply because the
 components did not compose in earlier versions of Ada, so that this will make no
 difference.)
 
@@ -154,7 +150,7 @@
 the composed equality. For example, a call to the "=" operator for an
 untagged record type R ought to yield the same answer as a corresponding call
 to the predefined "=" operator for a one-field record type whose one
-component is type R.
+component is of type R.
 
 If that is not possible (or the semantics would change from Ada 2005 for
 a direct call on "="), then you should get a compile-time or run-time error
@@ -184,7 +180,7 @@
     This preserves the principle that "=" always calls the same
     body no matter what view of the type is available. Otherwise the
     implementation of "=" called could depend on the view of the
-    of the type, which would be a nightmare for composition.
+    type, which would be a nightmare for composition.
 
  3) Referencing a predefined "=" operator in a renames before
     overriding the "=" operator is treated as having "squirreling"
@@ -241,7 +237,9 @@
 shall be subtype conformant.>
 @dinst
 The explicit declaration of a primitive equality operator of an
-untagged record type shall occur before the type is frozen.
+untagged record type, if its profile is type conformant
+with that of the corresponding predefined equality operator,
+shall occur before the type is frozen.
 If the untagged record type has a nonlimited partial view, then the
 declaration shall occur in the visible part of the enclosing package.
 In addition to the places where Legality Rules normally apply (see 12.3),
@@ -257,8 +255,9 @@
 @dby
 For a type extension, predefined equality is defined in terms of the
 primitive [(possibly user-defined)] equals operator for the parent type
-and for any record components in the extension part, and predefined
-equality for any other components not inherited from the parent type.
+and for any components that have a record type in the extension part, and
+predefined equality for any other components not inherited from the
+parent type.
 
 For a derived type whose parent is an untagged record type, predefined equality
 is defined in terms of the primitive (possibly user-defined) equals operator of
@@ -2452,5 +2451,42 @@
     any matching components that are of a record type
 or
    any matching components that have a record type
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, October 6, 2009  4:28 PM
+
+In looking at AI05-0123, composability of equality, it seems a bit dodgy to relegate
+the explanation of what we mean by "primitive equality operator" to an AARM note:
+
+Currently we have:
+
+   Add after 4.5.2(9.7/2):
+     The explicit declaration of a primitive equality operator
+     of an untagged record type shall occur before the type is
+     frozen. ...
+
+       AARM Note: The phrase "equality operator" as used here
+       refers only to a function whose profile is type conformant
+       with that of the predefined equality operator for the
+       untagged record type.
+
+Couldn't we reword this to:
+
+     The explicit declaration of a primitive equality operator
+     of an untagged record type, if its profile is type conformant
+     with that of the corresponding predefined equality operator,
+     shall occur before the type is frozen. ...
+
+Although it is somewhat ambiguous whether the term "equality operator"
+means any function whose name is "=" or "/=", or only one that takes two operands
+of the same type and returns Boolean, it stills feels funny to relegate to an AARM NOTE
+the fact that this rule only applies to the latter.  Note that in 3.4(17/2) we go out
+of our way to qualify the rule there with "... would have a profile that is type
+conformant with the profile of the corresponding predefined equality operator...".
+It seems we ought to be consistent.
+
+Sorry I didn't notice this earlier...
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent