CVS difference for ais/ai-00334.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00334.txt

--- ais/ai-00334.txt	2003/08/01 01:40:08	1.2
+++ ais/ai-00334.txt	2004/07/27 23:00:59	1.3
@@ -1,4 +1,4 @@
-!standard 3.09.03      (04)                            03-07-30  AI95-00334/01
+!standard 3.09.03      (04)                            04-06-29  AI95-00334/02
 !standard 3.09.03      (06)
 !class binding interpretation 03-07-30
 !status work item 03-07-30
@@ -26,15 +26,13 @@
    type My_Key is new Root_Key with record
       X : Integer := 0;
    end record;
-   -- Predefined "=" does the right thing for equivalence of My_Key;
-   -- no need to define it explicitly.
 
 Should it be required to override "=" explicitly in this case? (Yes.)
 
 4.5.2(14) (and 3.4(17)) says that the predefined equality operator
 for a type extension is *not* inherited, but rather "incorporates"
 the primitive equality op of the parent type. However, the rules for
-for abstract subprograms (3.9.3(4-6)) don't mention this case -- they only
+abstract subprograms (3.9.3(4-6)) don't mention this case -- they only
 talk about inherited subprograms.
 
 !recommendation
@@ -43,22 +41,14 @@
 
 !wording
 
-Change 3.9.3(4):
-For a derived type, if the parent or ancestor type has an abstract primitive
-subprogram {which will be inherited (see 3.4)}, or a primitive function with a
-controlling result, then:
+Change 3.9.3(4-5):
+If a derived type has an implicitly declared primitive subprogram that is
+inherited or is the predefined equality operator, and the corresponding
+primitive subprogram of the parent or ancestor type is abstract or is a
+function with a controlling result, then:
 
-Add after 3.9.3(6):
-For a non-limited type extension, if the parent or ancestor type has an
-abstract primitive user-defined equality operator whose profile is type-conformant
-with predefined equality, then:
-* If the type extension is abstract, predefined quality for the type extension
-  is abstract.
-* Otherwise, the predefined equality operator shall be overridden with a
-  nonabstract subprogram. However, if the type is a generic
-  formal type, the operator need not be overridden for the formal type
-  itself; a nonabstract version will necessarily be provided by the actual
-  type.
+  * If the derived type is abstract or untagged, the implicitly declared
+    subprogram is abstract.
 
 !discussion
 
@@ -86,7 +76,7 @@
 
 Notes on the wording change.
 
-The existing 3.9(4-6) is:
+The existing 3.9.3(4-6) is:
 
 For a derived type, if the parent or ancestor type has an abstract primitive
 subprogram, or a primitive function with a controlling result, then:
@@ -99,24 +89,18 @@
   itself; a nonabstract version will necessarily be provided by the actual
   type.
 
-The interesting this about this is that neither 3.9(4) nor 3.9(6) talk about
-inherited subprograms. 3.9(4) says "has a abstract primitive subprogram",
+The interesting thing about this is that neither 3.9.3(4) nor 3.9.3(6) talk
+about inherited subprograms. 3.9.3(4) says "has an abstract primitive subprogram",
 without saying anything about the case of a routine which is not inherited.
 Thus, an abstract equality operator is included by this text, and a overriding
 is required. But, so are abstract primitive subprograms declared after the
 derived type which are also not inherited. And it fails to make predefined
 equality abstract for abstract types. So the existing text is no good.
 
-We could try to integrate the predefine equality wording into the existing
-text, but this leads to a morass, because the entire phrase "abstract primitive
-user-defined equality operator whose profile is type-conformant with predefined
-equality" has to be repeated before talking about predefined equality. We could
-try to give the item we're talking about a name, but it is not clear at all
-how to do that.
-
-The solution chosen is to duplicate the needed wording. While this is annoying,
-it at least preserves readability by avoiding the insertion of a big glob of
-text into each rule.
+The solution is to have 3.9.3(4) talk about "implicitly declared primitive
+subprograms", and then have 3.9.3(5) use this wording, rather than inherited.
+It's not necessary to change 3.9.3(6), as it refers to "the subprogram",
+meaning the subprogram mentioned in 3.9.3(4).
 
 !corrigendum 03.09.03(04)
 
@@ -124,30 +108,18 @@
 For a derived type, if the parent or ancestor type has an abstract primitive
 subprogram, or a primitive function with a controlling result, then:
 @dby
-For a derived type, if the parent or ancestor type has an abstract primitive
-subprogram {which will be inherited (see 3.4)}, or a primitive function with a
-controlling result, then:
+If a derived type has an implicitly declared primitive subprogram that is
+inherited or is the predefined equality operator, and the corresponding
+primitive subprogram of the parent or ancestor type is abstract or is a
+function with a controlling result, then:
 
-!corrigendum 03.09.03(06)
-
-@dinsa
-@xbullet<Otherwise, the subprogram shall be overridden with a nonabstract
-subprogram; for a type declared in the visible part of a package, the
-overriding may be either in the visible or the private part. However, if the
-type is a generic formal type, the subprogram need not be overridden for the
-formal type itself; a nonabstract version will necessarily be provided by the
-actual type.>
-@dinss
-For a non-limited type extension, if the parent or ancestor type has an
-abstract primitive user-defined equality operator whose profile is
-type-conformant with predefined equality, then:
-@xbullet<If the type extension is abstract, predefined quality for the type
-extension is abstract.>
-@xbullet<Otherwise, the predefined equality operator shall be overridden with a
-nonabstract subprogram. However, if the type is a generic
-formal type, the operator need not be overridden for the formal type
-itself; a nonabstract version will necessarily be provided by the actual
-type.>
+!corrigendum 03.09.03(05)
+@drepl
+@xbullet<If the derived type is abstract or untagged, the inherited subprogram
+is abstract.>
+@dby
+@xbullet<If the derived type is abstract or untagged, the implicitly declared
+subprogram is abstract.>
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent