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

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

--- ai12s/ai12-0080-1.txt	2013/10/22 03:07:55	1.1
+++ ai12s/ai12-0080-1.txt	2013/10/25 01:18:05	1.2
@@ -1,4 +1,4 @@
-!standard D.16.1(16/3)                                    13-10-21  AI05-0080-1/00
+!standard 3.9.3(6/2)                                      13-10-24  AI05-0080-1/01
 !class presentation 13-10-21
 !status work item 13-10-21
 !status received 13-06-16
@@ -19,7 +19,23 @@
 
 !question
 
-1) None yet.
+1) The following appears to be legal:
+
+    package Pack1 is
+        type T1 is abstract tagged record ... end record;
+        function Create (N : Integer) return T1 is abstract;
+    end Pack1;
+
+    package Pack2 is
+        type T2 is new Pak1.T1 with private;
+    private
+        type T2 is new Pak1.T1 with null record;
+    end Pack2;
+
+as Create is "a function with a controlling result" inherited
+by a private extension, as described in 3.9.3(6). But Create is
+abstract, and we don't want abstract subprograms of nonabstract
+tagged types. Should this be fixed? (Yes.)
 
 !recommendation
 
@@ -27,13 +43,45 @@
 
 !wording
 
-1) None yet.
+1) Modify 3.9.3(6):
 
-!discussion
+Otherwise, the subprogram shall be overridden with a nonabstract
+subprogram or, in the case of a private extension inheriting a {nonabstract}
+function with a controlling result, have a full type that is a null extension;
+for a type declared in the visible part of a package, the overriding may be
+either in the visible or the private part. Such a subprogram is said to
+@i<require  overriding>. 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.
 
-1) None yet.
-
+!discussion
 
+1) This problem was noted in the e-mail appendix to AI95-00391-1 (which
+originally defined this wording), but for some reason the fix was never
+applied. It obviously would make no sense to allow an abstract routine to
+be inherited but not be overridden for a nonabstract type (of any kind).
+
+
+!corrigendum 3.9.3(6)
+
+@drepl
+@xbullet<Otherwise, the subprogram shall be overridden with a nonabstract
+subprogram or, in the case of a private extension inheriting a function with
+a controlling result, have a full type that is a null extension; for a type
+declared in the visible part of a package, the overriding may be either in
+the visible or the private part. Such a subprogram is said to @i<require 
+overriding>. 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.>
+@dby
+@xbullet<Otherwise, the subprogram shall be overridden with a nonabstract
+subprogram or, in the case of a private extension inheriting a nonabstract
+function with a controlling result, have a full type that is a null extension;
+for a type declared in the visible part of a package, the overriding may be
+either in the visible or the private part. Such a subprogram is said to
+@i<require  overriding>. 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.>
 
 !ASIS
 
@@ -44,5 +92,58 @@
 No test needed.
 
 !appendix
+
+!topic Missing word in 3.9.3(6)?
+!reference 3.9.3(6)
+!from Adam Beneschan 13-08-08
+!discussion
+
+3.9.3(6) says:
+
+    Otherwise, the subprogram shall be overridden with a nonabstract
+    subprogram or, in the case of a private extension inheriting a
+                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    function with a controlling result, have a full type that is a
+    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^        
+    null extension; for a type declared in the visible part of a
+    package, the overriding may be either in the visible or the
+    private part. Such a subprogram is said to require
+    overriding. 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.
+
+Shouldn't the clause I marked say
+
+    or, in the case of a private extension inheriting a
+    **nonabstract** function with a controlling result, ...
+
+?  The intent is obviously that private extensions whose full type is
+a null extension don't have to override functions with controlling
+results.  But a function with a controlling result could also be
+abstract, and we don't want the rule to apply in that case.  Otherwise
+I think this would be legal:
+
+    package Pack1 is
+        type T1 is abstract tagged record ... end record;
+        function Create (N : Integer) return T1 is abstract;
+    end Pack1;
+
+    package Pack2 is
+        type T2 is new Pak1.T1 with private;
+    private
+        type T2 is new Pak1.T1 with null record;
+    end Pack2;
+
+It's really a bit of a nitpick since the intent is obvious, but I
+think it should be corrected.
+
+****************************************************************
+
+From: Adam Beneschan
+Sent: Thursday, August 8, 2013  8:01 PM
+
+Heh... I just noticed (9 years after the fact) that Tucker mentioned this
+at the end of AI95-391, but apparently it didn't get in ...
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent