CVS difference for arm/source/08.mss

Differences between 1.80 and version 1.81
Log of other versions for file arm/source/08.mss

--- arm/source/08.mss	2008/11/26 23:41:02	1.80
+++ arm/source/08.mss	2009/07/02 04:51:28	1.81
@@ -1,10 +1,10 @@
 @Part(08, Root="ada.mss")
-@Comment{$Date: 2008/11/26 23:41:02 $}
+@Comment{$Date: 2009/07/02 04:51:28 $}
 @LabeledSection{Visibility Rules}
 @Comment{$Source: e:\\cvsroot/ARM/Source/08.mss,v $}
-@Comment{$Revision: 1.80 $}
+@Comment{$Revision: 1.81 $}
 @redundant[The rules defining the scope of declarations and the rules defining
@@ -2560,16 +2560,21 @@
 renaming-as-body has its own elaboration check.]}
 For a call on a renaming of a dispatching subprogram that is overridden,
 if the overriding occurred before the renaming, then the body executed
 is that of the overriding declaration,
 even if the overriding declaration is not visible at the place of the renaming;
-otherwise, the inherited or predefined subprogram is called.
+otherwise, the inherited or predefined subprogram is
+called.@Chg{Version=[3],New=[ A corresponding rule applies to a call on a
+renaming of a predefined equality operator for an untagged record type.],Old=[]}
 Note that whether or not the renaming is itself primitive has
 nothing to do with the renamed subprogram.
-Note that the above rule is only for tagged types.
+Note that the above rule is only for tagged types@Chg{Version=[3],New=[ and
+equality of untagged record types],Old=[]}.
 @leading@keepnext@;Consider the following example:
@@ -2689,6 +2694,19 @@
+  @ChgRef{Version=[3],Kind=[Added],ARef=[AI05-0123-1]}
+  @ChgAdded{Version=[3],Text=[@Defn{inconsistencies with Ada 95}@b<Amendment 2:>
+  Renaming of user-defined untagged record equality is now defined to call the
+  overridden body so long as the overriding occurred before the renames.
+  This could change the body called in unusual cases; the change is necessary
+  to preserve the principle that the body called for an explicit call to
+  "=" (via a renames in this case) is the same as the one inherited for a
+  derived type and used in generics. Note that any renamings before the
+  overriding will be unchanged. Any differences caused by the change will be
+  rare and most likely will fix a bug.]}
   @ChgAdded{Version=[2],Text=[@Defn{extensions to Ada 95}
@@ -3182,6 +3200,21 @@
+@ChgAdded{Version=[3],Text=[If the expected type of a construct is @i<T1> and
+the actual type of the construct is @i<T2>, then @i<T2> shall be convertible to
+@i<T1> (see @RefSecNum{Type Conversions}).@Defn2{Term=[implicit conversion],
+  @ChgRef{Version=[3],Kind=[AddedNormal]}
+  @ChgAdded{Version=[3],Text=[This rule prevents an implicit conversion that
+  would be illegal if it was an explicit conversion. For instance, this
+  prevents assigning an access-to-constant value into a stand-alone anonymous
+  access-to-variable object. It also covers convertibility of the designated
+  type and accessibility checks.]}
 A complete context shall have at least one acceptable interpretation;
 if there is exactly one, then that one is chosen.
@@ -3460,5 +3493,11 @@
   (like object renames and qualified expressions). This fixes a hole in Ada 95
   that appears to prohibit using @nt{aggregate}s, 'Access, character literals,
   string literals, and @nt{allocator}s in qualified expressions.]}
+  @ChgRef{Version=[3],Kind=[AddedNormal],ARef=[AI05-0102-1]}
+  @ChgAdded{Version=[3],Text=[@b<Amendment 2 correction:> Added a requirement
+  here that implicit conversions are convertible to the appropriate type.
+  This rule was scattered about the Standard, we moved a single generalized
+  version here.]}

Questions? Ask the ACAA Technical Agent