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

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

--- ai12s/ai12-0269-1.txt	2018/03/30 07:48:57	1.2
+++ ai12s/ai12-0269-1.txt	2018/04/05 06:06:03	1.3
@@ -1,6 +1,16 @@
-!standard 6.5.1(0)                                  18-03-28  AI12-0269-1/02
+!standard 6.5.1(0)                                 18-04-04  AI12-0269-1/03
+!standard 6.5.1(1/3)
+!standard 6.5.1(3.1/3)
+!standard 6.5.1(3.4/3)
 !standard 6.5.1(5/2)
+!standard 6.5.1(6/2)
+!standard 6.5.1(7/2)
+!standard J.15.2(2/3)
+!standard J.15.2(3/3)
+!standard J.15.2(4/3)
 !class Amendment 18-03-29
+!status Amendment 1-2012 18-04-04
+!status ARG Approved 7-0-2  18-04-02
 !status work item 18-03-29
 !status received 18-03-24
 !priority Low
@@ -49,9 +59,10 @@
 
 Add after 6.5.1(5/2):
 
-Any return statement in a nonreturning function or generic function shall have
-an expression that is solely a raise_expression or a call on a nonreturning
-function.
+Any return statement that applies to a nonreturning function or generic
+function shall be a simple_return_statement with an expression that is a
+raise_expression, a call on a nonreturning function, or a parenthesized 
+expression of one of these.
 
 AARM Ramification: We still require at least one return statement in a function;
 we just require that all such return statements don't actually return a value.
@@ -59,7 +70,8 @@
 [Editor's note: We don't need an analog of 6.5.1(9/2) for functions; all functions
 have this semantics.]
 
-Change "procedure" to "subprogram" in J.15.2(2/3) and J.15.2(3/3).
+Change "procedure" to "subprogram" in J.15.2(2/3), J.15.2(3/3) (except "null
+procedure"), and J.15.2(4/3).
 
 !discussion
 
@@ -70,15 +82,16 @@
 We don't require that all return statements be removed from a
 "No_Return" function, because that would have the effect of making an
 illegal program (a return-less function) into a legal program, something
-we try to avoid doing with a pragma or aspect specification.  Because of the
+we try to avoid doing with a pragma or aspect specification. Because of the
 availability of the raise expression, it is now convenient to bury the
 raise statement "inside" the return statement.
 
-We could go further to accommodate legacy code, and relax the requirement
-that all return statements return a raise expression or a non-returning
-call.  In particular, we could allow an arbitrary return statement so
-long as it immediately follows a raise statement or a call on a
-No_Return procedure.
+We considered going further to accommodate legacy code, and relax the
+requirement that all return statements return a raise expression or a
+non-returning call. In particular, we could have allowed an arbitrary return
+statement so long as it immediately follows a raise statement or a call on a
+No_Return procedure. This was judged to be an unnecessarily complication for
+a feature that is not expected to be used often.
 
 !example
 
@@ -88,6 +101,108 @@
         return raise Program_Error with "type T not copyable";
     end Copy;
 
+!corrigendum 6.5.1(0)
+
+@drepl
+Nonreturning Procedures
+@dby
+Nonreturning Subprograms
+
+!corrigendum 6.5.1(1/3)
+
+@drepl
+Specifying aspect No_Return to have the value True
+indicates that a procedure cannot return normally; it may propagate
+an exception or loop forever.
+@dby
+Specifying aspect No_Return to have the value True
+indicates that a subprogram cannot return normally; it may propagate
+an exception or loop forever.
+
+!corrigendum 6.5.1(3.1/3)
+
+@drepl
+For a procedure or generic procedure, the following language-defined
+representation aspect may be specified:
+@dby
+For a subprogram or generic subprogram, the following language-defined
+representation aspect may be specified:
+
+!corrigendum 6.5.1(3.4/3)
+
+@drepl
+If a generic procedure is nonreturning, then so are its instances. If a procedure
+declared within a generic unit is nonreturning, then so are the corresponding copies of
+that procedure in instances.
+@dby
+If a generic subprogram is nonreturning, then so are its instances. If a subprogram
+declared within a generic unit is nonreturning, then so are the corresponding copies of
+that subprogram in instances.
+
+
+!corrigendum 6.5.1(5/2)
+
+@dinsa
+A return statement shall not apply to a nonreturning procedure or generic
+procedure.
+@dinst
+Any return statement that applies to a nonreturning function or generic
+function shall be a @fa<simple_return_statement> with an @fa<expression>
+that is a @fa<raise_expression>, a call on a nonreturning function, or
+a parenthesized @fa<expression> of one of these.
+
+!corrigendum 6.5.1(6/2)
+
+@drepl
+A procedure shall be non-returning if it overrides a dispatching
+non-returning procedure. In addition to the places where Legality
+Rules normally apply (see 12.3), this rule applies also in the private
+part of an instance of a generic unit.
+@dby
+A subprogram shall be non-returning if it overrides a dispatching
+non-returning subprogram. In addition to the places where Legality
+Rules normally apply (see 12.3), this rule applies also in the private
+part of an instance of a generic unit.
+
+!corrigendumm 6.5.1(7/2)
+
+@drepl
+If a renaming-as-body completes a non-returning procedure declaration,
+then the renamed procedure shall be non-returning.
+@dby
+If a renaming-as-body completes a non-returning subprogram declaration,
+then the renamed subprogram shall be non-returning.
+
+!corrigendum J.15.2(2/3)
+
+@drepl
+@xcode<@ft<@b<pragma> No_Return (@i<procedure_>@fa<local_name>{, @i<procedure_>@fa<local_name>});>>
+@dby
+@xcode<@ft<@b<pragma> No_Return (@i<subprogram_>@fa<local_name>{, @i<subprogram_>@fa<local_name>});>>
+
+!corrigendum J.15.2(3/3)
+
+@drepl
+Each @i<procedure_>@fa<local_name> shall denote one or more procedures or
+generic procedures. The @i<procedure_>@fa<local_name> shall not denote a null
+procedure nor an instance of a generic unit.
+@dby
+Each @i<subprogram_>@fa<local_name> shall denote one or more subprograms or
+generic subprograms. The @i<subprogram_>@fa<local_name> shall not denote a null
+procedure nor an instance of a generic unit.
+
+!corrigendum J.15.2(4/3)
+
+@drepl
+@fa<Pragma> No_Return specifies that the No_Return aspect (see 6.5.1) for each
+procedure denoted by each @fa<local_name> given in the @fa<pragma> has the
+value True.
+@dby
+@fa<Pragma> No_Return specifies that the No_Return aspect (see 6.5.1) for each
+subprogram denoted by each @fa<local_name> given in the @fa<pragma> has the
+value True.
+
+
 !ASIS
 
 Probably won't need an interface change, this is an existing aspect.
@@ -1571,5 +1686,64 @@
 your hands back to type the next command. :-) GNAT is far from that today,
 even on relatively small programs. Same for Janus/Ada. They build about the
 same speed, at least on the smallish programs that I've used both.
+
+****************************************************************
+
+From a private discussion about the Editorial Review comments of Randy
+Brukardt:
+
+Randy Brukardt:
+
+"procedure" needs to be changed in J.15.2(4/3) as well, it shouldn't be changed
+in "null procedure" in J.15.2(3/3).
+
+The return statement Legality Rule is in part:
+
+"... an expression that is a raise_expression or a call on a nonreturning function"
+
+Humm...actually, we have a problem with this wording. I tend to write:
+
+    return (raise Program_Error);
+
+because I can't remember if the parens are required or not (they're required for
+conditional expressions and the like, but raise expressions are different).
+However, the above rule makes that illegal, as the above is a parenthesized
+expression, not either of the things allowed. We need at least to allow
+parenthesized raise_expressions and function calls lest the rule be ridiculous.
+One could imagine going further and also allowing qualified expressions and
+conditional expressions where all of the dependent expressions qualify -- that
+would be best for expression functions. [But that would require reopening the
+AI.]
+
+Thus, we need at least:
+
+"... an expression that is a raise_expression, a call on a nonreturning function,
+or a parenthesized expression of one of these."
+
+Steve Baird:
+
+... like Randy, I always put parens around a raise expression if the enclosing 
+construct doesn't already provide them. If a compiler rejected
+
+    return (raise Program_Error);
+
+then I would probably be annoyed (assuming that for some reason I was writing
+a No_Return function; I don't know why I would be doing that).
+
+...
+I think that opening the door wide enough to allow a parenthesized expression
+is pushing the bounds of editorial review (justified in part by Randy's
+observation that folks forget that the syntax for these guys does not include 
+parens), and anything more (e.g., allowing conditional expressions) is well
+outside of those bounds.
+
+Tucker Taft:
+
+This [the wording Randy proposed above] seems more than adequate.  Anything 
+more seems silly.
+
+Jeff Cousins:
+
+I'm OK with [considering] it as editorial review.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent