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

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

--- ai12s/ai12-0170-1.txt	2015/06/23 01:51:40	1.2
+++ ai12s/ai12-0170-1.txt	2015/10/13 22:00:34	1.3
@@ -1,4 +1,5 @@
-!standard 6.1.1(7/4)                                      15-06-17  AI05-0170-1/01
+!standard 3.9.3(7)                                   15-10-13  AI05-0170-1/02
+!standard 6.1.1(7/4)
 !standard 6.1.1(18.2/4)
 !standard 7.3.2(5/4)
 !class binding interpretation 15-06-17
@@ -47,6 +48,13 @@
 
 !wording
 
+Modify 3.9.3(7):
+
+A call on an abstract subprogram{, unless it appears within an aspect
+specification of an abstract subprogram,} shall be a dispatching call;
+[Redundant: nondispatching calls to an abstract subprogram are not
+allowed.]
+
 Modify 6.1.1(7/4):
 
 Within the expression for a Pre'Class or Post'Class aspect for a primitive
@@ -59,6 +67,10 @@
 that can be applied to such names are those defined for such a formal derived
 type. 
 
+  AARM Ramification: The operations of NT are also nonabstract, so the
+  rule against a call of an abstract subprogram does not trigger for a
+  class-wide precondition or postcondition.
+
 Modify 6.1.1(18/4):
 
 If a Pre'Class or Post'Class aspect is specified for a primitive subprogram S
@@ -74,13 +86,16 @@
 expression for the Type_Invariant aspect of a type T, the type of this current
 instance is T. Within an invariant expression for the Type_Invariant'Class
 aspect of a type T, the type of this current instance is interpreted as though
-it had a (notional) type NT that is a visible formal derived type whose
-ancestor type is T. The effect of this interpretation is that the only
-operations that can be applied to this current instance are those defined for
-such a formal derived type. 
+it had a (notional) {nonabstract} type NT that is a visible formal derived
+type whose ancestor type is T. The effect of this interpretation is that the
+only operations that can be applied to this current instance are those defined
+for such a formal derived type. 
 
 !discussion
 
+We allow calls on abstract subprograms if they are within the aspect
+specification of an abstract subprogram.
+
 6.1.1(18-18.2/4) was intended to apply only to operations of actual descendants
 and not to the original operation. 6.1.1(18.1/4) doesn't make much sense
 otherwise, and one cannot daisy-pick readings that they like for individual
@@ -180,6 +195,27 @@
       with Pre'Class => F1 (Ifc'Class(Y));
   end Pkg5;
 
+---
+
+Another troublesome example:
+
+   package Pkg6 is
+      type AT is abstract null record;
+   
+      function F1 (X : At) return Boolean is abstract;
+
+      function F2 (Y : At) return Boolean 
+         with Pre'Class => F1 (Y);
+      
+   end Pkg6;
+
+   O : At'Class := ...;
+
+   if F2(At(O)) then
+       ... -- OK, but the precondition calls F1 for AT.
+       
+This is illegal by 3.9.3(7), including after the above modification.
+
 !ASIS
 
 No ASIS effect.
@@ -492,6 +528,27 @@
 This is surely legal, as the call to F1 is now always dispatching.
 
 Anyway, we have to have some fun AI for this meeting. :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 13, 2015  4:53 PM
+
+> This is a minor update. [Version /02 of the AI - Editor.]
+
+A bit too minor, I'd say. It leaves the **TBD in the !discussion, and leaves
+the editor's rant that follows it (and even adds to it!) without explaining
+how you addressed the issues that I was ranting about. A finished AI should
+not say "I have no solution for the original question"!
+
+And you added:
+
+We allow calls on abstract subprograms if they are within the aspect
+specification of an abstract subprogram.
+
+which is obviously true from reading the !wording; but you give no clue as to
+why that's OK or how come no actual call on an abstract routine will result.
+(And if you can't explain that, we have a problem. :-)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent