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

--- ai12s/ai12-0344-1.txt	2020/01/30 04:12:16	1.4
+++ ai12s/ai12-0344-1.txt	2020/06/09 23:45:37	1.5
@@ -1,6 +1,8 @@
-!standard 5.5.3(16/5)                                  20-01-12  AI12-0344-1/02
+!standard 5.5.3(16/5)                                  20-06-09  AI12-0344-1/03
 !standard 5.5.3(20/5)
 !standard 5.5.3(22/5)
+!standard 9.10.1(22/5)
+!standard H.4(12)
 !class Amendment 19-09-30
 !status work item 19-09-30
 !status received 19-08-19
@@ -10,11 +12,14 @@
 !summary
 
 Allows_Exit and Parallel_Iterator can only be applied to subprograms with
-a single access-to-subprogram parameter.
+a single access parameter of an access-to-subprogram type.
 
 Aspect Parallel_Calls is defined to check that a subprogram can be called
 in parallel.
 
+The No_Exceptions restriction also disallows use of early exits from
+procedural iterators.
+
 !problem
 
 The legality requirement for Allows_Exit and Parallel_Iterator aspects says
@@ -24,8 +29,14 @@
 description of the semantics of the aspects?
 
 If the user explicitly passes a subprogram to a subprogram with
-Parallel_Iterator => True, there is no checking on that subprogram (unlike
-what happens when the subprogram is used in a procedural iterator loop).
+Parallel_Iterator => True, there is no checking on that subprogram
+(unlike what happens when the subprogram is used in a procedural
+iterator loop).
+
+If the No_Exceptions restriction is in place (see H.4(12)), the
+implementation should not be expected to support an early exit from a
+procedural iterator, as that is likely to use some mechanism based on,
+or similar to, exception handling.
 
 !proposal
 
@@ -74,6 +85,16 @@
     exist. [Redundant: Such checks need not be repeated at each call of the
     subprogram in a parallel iteration context.]
 
+Modify RM H.4(12):
+
+ No_Exceptions
+        Raise_statements and exception_handlers are not allowed. No
+        language-defined runtime checks are generated; however, a
+        runtime check performed automatically by the hardware is
+        permitted. {The callable entity associated with a
+        procedural_iterator (see 5.5.3) is considered to not allow exit,
+        independent of the value of its Allows_Exit aspect.}
+
 !discussion
 
 As indicated in the !problem, to prevent ambiguity, we limit the aspects
@@ -88,9 +109,16 @@
 expected to be called by a subprogram with the Parallel_Iterator aspect,
 or to be called in other parallel iteration contexts. Such a subprogram
 is checked according to the Confict_Check_Policy in effect, to determine
-whether it can be safely called concurrently. This enables some
-conflict checking to be performed modularly, without relying on a
-specified Global aspect.
+whether it can be safely called concurrently. This enables some conflict
+checking to be performed modularly, without relying on a specified
+Global aspect.
+
+Some concerns about implementability of an early exit from a procedural
+iterator have been expressed, particularly in target environments where
+exception handling is not supported. We therefore make the
+No_Exceptions restriction also disallow early exits from procedural
+iterators, as it is likely that such early exits will depend on some
+sort of mechanism resembling exception handling.
 
 !ASIS
 
@@ -156,30 +184,30 @@
 Sent: Saturday, August 24, 2019  10:52 PM
 
 >> ...
->> My reasoning for having the Process parameter first is that all my 
+>> My reasoning for having the Process parameter first is that all my
 >> library calls have a Process parameter.
->> It is the only common parameter, so it makes sense to have it as the 
+>> It is the only common parameter, so it makes sense to have it as the
 >> first parameter for consistency.
-> 
-> The proposed syntax for the procedural iterator allows you to omit the 
+>
+> The proposed syntax for the procedural iterator allows you to omit the
 > "<>" if the "process" parameter is last, which is the reason I put it last.
 
 [The above quote is from a thread filed in AI12-0357-1. - Editor.]
 
 And from another recent email....
 
-> I believe we have a bug in the legality requirement for Allows_Exit 
-> and Parallel_Iterator aspects.  It currently says that the callable 
-> entity shall have at least one parameter of an anonymous 
-> access-to-subprogram type.  I don't think that really makes sense.  I 
-> think we should say "exactly one" because otherwise how do we know 
-> which parameter is the "loop body procedure" which is mentioned in the 
+> I believe we have a bug in the legality requirement for Allows_Exit
+> and Parallel_Iterator aspects.  It currently says that the callable
+> entity shall have at least one parameter of an anonymous
+> access-to-subprogram type.  I don't think that really makes sense.  I
+> think we should say "exactly one" because otherwise how do we know
+> which parameter is the "loop body procedure" which is mentioned in the
 > description of the semantics of the aspects.
 
-My question is, if we are changing this to only allow "exactly one" parameter 
-of an anonymous access-to-subprogram type, then it seems a bit of a weird 
-restriction that it has to be the last parameter to allow omitting the <>. 
-If there can only be one such parameter, why not allow omitting the <> 
+My question is, if we are changing this to only allow "exactly one" parameter
+of an anonymous access-to-subprogram type, then it seems a bit of a weird
+restriction that it has to be the last parameter to allow omitting the <>.
+If there can only be one such parameter, why not allow omitting the <>
 regardless of which parameter it is?
 
 ****************************************************************
@@ -187,9 +215,9 @@
 From: Tucker Taft
 Sent: Sunday, August 25, 2019  7:47 AM
 
-Interesting point.  Worth discussing at the ARG meeting, if not before.  I 
-was suggesting it being a requirement only when Allows_Exit or 
-Parallel_Iterator is specified True, but it is not a big leap to make it a 
+Interesting point.  Worth discussing at the ARG meeting, if not before.  I
+was suggesting it being a requirement only when Allows_Exit or
+Parallel_Iterator is specified True, but it is not a big leap to make it a
 general requirement for any use of the procedural iterator.
 
 ****************************************************************