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

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

--- ai12s/ai12-0220-1.txt	2017/04/21 05:43:53	1.2
+++ ai12s/ai12-0220-1.txt	2017/06/10 04:24:23	1.3
@@ -1,4 +1,4 @@
-!standard 6.1.1(1/4)                                  17-04-07  AI12-0220-1/01
+!standard 6.1.1(1/4)                                  17-06-09  AI12-0220-1/02
 !standard 6.1.1(39/3)
 !class Amendment 17-04-07
 !status work item 17-04-07
@@ -20,13 +20,87 @@
 
 !wording
 
-** Assigned to Steve Baird
+6.1.1
+
+In 1/4, "For a noninstance subprogram, a generic subprogram, or an entry"
+becomes "For a noninstance subprogram, a generic subprogram, an entry, or
+an access-to-subprogram type".
+
+In 2/3 and 4/3, "for a callable entity" becomes "for a callable entity
+or an access-to-subprogram type".
+
+Intent: Pre and Post aspects may be specified for access-to-subprogram types.
+
+In 28/3 "that denotes a function declaration" becomes "that denotes a
+  function declaration or an access-to-function type (that is, an
+  access-to-subprogram type whose designated profile is a function profile)".
+
+In 29/3, "Within a postcondition expression for function F" becomes
+"Within a postcondition expression".
+
+Intent: 'Result works for access-to-subp postconditions.
+
+
+Replace 39/3 with:
+  For a call via an access-to-subprogram value, precondition and
+  postcondition checks performed are as determined by the subprogram or entry
+  denoted by the prefix of the Access attribute reference that produced the
+  value. In addition, before any such precondition checks are performed,
+  any precondition associated with the access-to-subprogram type is checked
+  Similarly, after any such postcondition checks are performed, any
+  postcondition associated with the access-to-subprogram type is checked.
+  More specifically, a call via an access-to-subprogram value is
+  equivalent (with respect to dynamic semantics) to call to a notional
+  "wrapper" subprogram which has the Pre and Post aspects and the profile of the
+  access-to-subprogram type and whose body contains (and returns, in the case
+  of a function) only a call to the designated subprogram. [This equivalence,
+  determines, for example, the point at which the constant associated with
+  an Old attribute reference in the Post aspect for an access-to-subprogram
+  type is elaborated and finalized. Note that in the case of type conversion
+  between two access-to-subprogram types, the Pre and Post aspects of the
+  source type of the conversion play no role in any subsequent call via
+  the conversion result; only the Pre and Post aspects of the target type
+  of the conversion are relevant in that case. The same applies in the
+  case of a "conversion" (using the term loosely) which is accomplished by
+  combining a dereference and a 'Access attribute reference, as in
+  Some_Pointer.all'Access.]
+
+Intent: This is the heart of the matter - the dynamics semantics of a
+  call to Ptr.all where Pre/Post has been specified for Ptr's type.
+
+Question: Is this overspecified? Do we want an implementation permission
+   here allowing the Pre/Post checks of the access-to-subprogram type
+   to be interspersed with those of the designated subprogram?
+
+====
+
+13.1.1
+
+In 12/5. "If the associated declaration is for a subprogram or entry, the
+names of the formal parameters are directly visible" becomes "If the associated
+declaration is for a subprogram, an entry, or an access-to-subprogram type,
+the names of the formal parameters are directly visible".
+
+Intent: In Pre/Post for an access-to-subp, ok to mention parameters,
+'Result and 'Old.
+
+Question: Could this possibly introduce an incompatibility? If so,
+  then do we want to restrict this rule (in the new access-to-subprogram case)
+  to apply only in the case of a Pre or Post aspect specification.
+
+A more restrictive version of this rule might be to leave sentence
+in 12/5 unmodified and instead append something like
+   "Formal parameter names are similarly directly visible in
+   a Pre or Post aspect specification for an access-to-subprogram type".
+immeditely afterwards.
+
+
 
-Notes: The basic idea only needs modifying 6.1.1(1/4) to allow Pre/Post on
-access-to-subprogram types, and 6.1.1(39/3) to say that Pre/Post of the
-access type is also evaluated.
+!discussion
+
+** Assigned to Steve Baird
 
-We also need to consider doing the same for formal subprograms (important)
+We also need to consider allowing Pre/Post for formal subprograms (important)
 and for renames (not important, other than to be consistent with formal
 subprograms).
 
@@ -38,9 +112,7 @@
 This latter issue may be better split to a separate-but-related AI; I'll
 leave that to Mr. Baird.
 
-!discussion
-
-** Assigned to Steve Baird
+---
 
 We definitely need to explain here why we're not making any attempt at
 matching. It seems to me that is a job for separate tools (and style rules??),
@@ -645,11 +717,11 @@
 From: Randy Brukardt
 Sent: Friday, April  7, 2017  10:13 PM
 
->    (1) Allow a separate declaration for closure access types, so that 
-> we can give properties of the type as needed (contracts in particular, 
-> but also possibly conventions, alignment, or anything else that can 
+>    (1) Allow a separate declaration for closure access types, so that
+> we can give properties of the type as needed (contracts in particular,
+> but also possibly conventions, alignment, or anything else that can
 > get defined by an aspect);
->    (2) Allow giving a name for closure access types, so one does not 
+>    (2) Allow giving a name for closure access types, so one does not
 > have to repeat a given profile in many subprogram declarations;
 >    (3) Allow closure access types in more contexts (local objects?
 > components? etc.);
@@ -778,10 +850,10 @@
 From: Erhard Ploedereder
 Sent: Friday, April 14, 2017  12:55 PM
 
-> A more radical idea is to get rid of "access" completely and talk 
-> about "subprogram types."  Bob Duff pushed a bit for that originally, 
-> and it should probably be on the table.  These would of course be of a 
-> limited type again.  This is somewhat related to lambda expressions, 
+> A more radical idea is to get rid of "access" completely and talk
+> about "subprogram types."  Bob Duff pushed a bit for that originally,
+> and it should probably be on the table.  These would of course be of a
+> limited type again.  This is somewhat related to lambda expressions,
 > aka function expressions.
 
 In the end, I think this is much preferable to subprogram access types (even
@@ -828,14 +900,14 @@
 From: Bob Duff
 Sent: Friday, April 14, 2017  4:27 PM
 
-> I agree "access" is noise, but not necessarily the "not null". Because 
+> I agree "access" is noise, but not necessarily the "not null". Because
 > I often use:
-> 
+>
 >     procedure P (...; Logger : access procedure (Msg : String) := null);
-> 
-> to provide an optional debugging log. This is the best way (IMHO) to 
-> add debugging to Pure and Preelaborated packages (in the latter case, 
-> Ada 2012 has another option, but for code portable to non-GNAT 
+>
+> to provide an optional debugging log. This is the best way (IMHO) to
+> add debugging to Pure and Preelaborated packages (in the latter case,
+> Ada 2012 has another option, but for code portable to non-GNAT
 > compilers the above is best).
 
 I never do that.  I don't want to scatter "if Logger /= null..."
@@ -843,14 +915,14 @@
 that does nothing, then write a procedure that does nothing.  Plus null might
 mean something else (e.g. "send the logs to a default location").
 
->... There is no logging if the subprogram is null (this is often the  
+>... There is no logging if the subprogram is null (this is often the
 >normal case).
 
 For logging, yes.  But it's not often you want a do-nothing default for
 anon-access-to-subp params.
 
-> Without the null, one has to use a dummy routine and that could be 
-> substantially more expensive (calls dumping pipelines on modern 
+> Without the null, one has to use a dummy routine and that could be
+> substantially more expensive (calls dumping pipelines on modern
 > machines) and surely clutters the code
 
 Clutters the code less than "if Logger /= null".
@@ -871,7 +943,7 @@
 From: Bob Duff
 Sent: Friday, April 14, 2017  4:48 PM
 
-> For logging, yes.  But it's not often you want a do-nothing default 
+> For logging, yes.  But it's not often you want a do-nothing default
 > for anon-access-to-subp params.
 
 FWIW, in the gnat sources, I see about 230 anon-access-to-subp params.
@@ -901,7 +973,7 @@
 Sent: Friday, April 14, 2017  5:22 PM
 
 > I never do that.  I don't want to scatter "if Logger /= null..."
-> all over the place.  Plus it just seems kludgy -- if you want a 
+> all over the place.  Plus it just seems kludgy -- if you want a
 > procedure that does nothing, then write a procedure that does nothing.
 
 I don't want a routine that does nothing, I don't want any logging at all.
@@ -916,7 +988,7 @@
 to get executed (the code size used to matter, too).
 
 ...
-> For logging, yes.  But it's not often you want a do-nothing default 
+> For logging, yes.  But it's not often you want a do-nothing default
 > for anon-access-to-subp params.
 
 I would have just said "it's not often you want ... anon-access-to-subp
@@ -924,7 +996,7 @@
 and Preelaborated packages make the normal solution impossible.
 
 ...
-> Anyway, presumably "X: not null access procedure(...)" will still be 
+> Anyway, presumably "X: not null access procedure(...)" will still be
 > legal.  I would strongly object if "X:
 > procedure(...)" allowed X to be null.
 
@@ -942,12 +1014,29 @@
 
 ****************************************************************
 
-From: Jeam-Pierre Rosen
+From: Jean-Pierre Rosen
 Sent: Friday, April 14, 2017  11:47 PM
 
-> For what it is worth in ParaSail, there are subprogram values, and a 
+> For what it is worth in ParaSail, there are subprogram values, and a
 > "null" procedure value does nothing.
 
 Too bad you didn't call it "OM" ...
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, June  9, 2017  6:50 PM
+
+Here is a first cut at wording for this AI. (This is version /02 of the AI
+ - Editor.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June  9, 2017  8:59 PM
+
+Thanks. We still need a !problem, !summary, and !discussion. And for me at
+least, we need this to work on generic formal subprograms, as those are an
+access-to-subprogram analogue.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent