CVS difference for ai12s/ai12-0413-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0413-1.txt

--- ai12s/ai12-0413-1.txt	2020/12/05 01:32:41	1.1
+++ ai12s/ai12-0413-1.txt	2020/12/11 22:22:26	1.2
@@ -1,8 +1,10 @@
-!standard 3.9.3(7)                                     20-12-03  AI12-0413-1/01
+!standard 3.9.3(7)                                     20-12-11  AI12-0413-1/02
 !standard 4.5.2(14.1/3)
 !standard 4.5.2(24.1/3)
 !standard 12.5(8/3)
 !class binding interpretation 20-12-03
+!status Amendment 1-2012 20-12-11
+!status ARG Approved 15-0-0  20-12-09
 !status work item 20-12-03
 !status received 20-11-28
 !priority Low
@@ -21,32 +23,32 @@
 
 There seems to be no rule to prevent the following from compiling:
 
-procedure Test_Inst is
- generic
-    type Formal_T is private;
-    with function F (L, R : Formal_T) return Boolean is "=";  package Gen is  end Gen;
-
- package body Gen is
-    I, J : Formal_T;
-    B : Boolean := I = J;
-    C : Boolean := F(I, J);
- end Gen;
-
- type T is range 1..10;
- function "=" (L, R : T) return Boolean is abstract;
-
- package Instance is new Gen (T);
-begin
- null;
-end Test_Inst;
+ procedure Test_Inst is
+   generic
+      type Formal_T is private;
+      with function F (L, R : Formal_T) return Boolean is "=";  
+   package Gen is  
+   end Gen;
+
+   package body Gen is
+      I, J : Formal_T;
+      B : Boolean := I = J;
+      C : Boolean := F(I, J);
+   end Gen;
+
+   type T is range 1..10;
+   function "=" (L, R : T) return Boolean is abstract;
+
+   package Instance is new Gen (T);
+ begin
+   null;
+ end Test_Inst;
 
 However, this seems to allow calling an abstract function.
 
-Should the above be illegal, or raise Program_Error? (Neither; if T is an 
-elementary type it calls the predefined "=".)
+Should the above be illegal, or raise Program_Error? (Neither; because T is 
+an elementary type it calls the predefined "=".)
 
-What happens if we change "T" to be a record type? (Program_Error is raised.)
-
 !recommendation
 
 Whether the above silently uses the predefined "=" or raises Program_Error 
@@ -154,6 +156,21 @@
 
 !discussion
 
+A different answer would have been given had the type T in the question been
+a record type. In that case, the primitive "=" is used in the generic, and
+4.5.2(24.1/3) would apply, so Program_Error would be raised. As mentioned in the
+new AARM note in 12.5, any such equality operators in a generic specification
+are rechecked in an instance, making the instance illegal.
+
+Had the type T in the question been an array type, the answer would be the same
+as for a scalar type - the predefined "=" would reimerge and the abstract "="
+would be ignored.
+
+The original "(implicit)" in 4.5.2(24.1/3) does not recognize all of the 
+cases where Program_Error can arise (the generic case was apparently not
+considered), so we remove "(implicit)" and replace it with some "redundant" 
+wording that explains the two cases where Program_Errors can arise.
+
 The rule given in RM 4.5.2(14.1/3), which we propose to delete, is followed by 
 an AARM note (which we also propose to delete) which implies that it solves the
 problem that can arise in an instance of a generic, but it only solves the 
@@ -161,12 +178,8 @@
 in paragraph 14.1/3 about derived types is adequate to prevent reemergence of
 predefined "=" for an untagged record type, but it doesn't say anything about
 non-derived types, nor does it deal properly with the case where the derived 
-type has its own user-defined "=" routine.
-
-The original "(implicit)" in 4.5.2(24.1/3) no longer recognizes all of the 
-cases where Program_Error can arise, so we remove "(implicitly)" and replace
-it with some "redundant" wording that explains the two cases where 
-Program_Errors can arise.
+type has its own user-defined "=" routine. Once we fix those cases, the fix
+covers this case as well and there is no other need for this rule.
 
 !example
 

Questions? Ask the ACAA Technical Agent