CVS difference for ais/ai-00329.txt

--- ais/ai-00329.txt	2004/03/02 01:56:05	1.3
+++ ais/ai-00329.txt	2004/03/02 04:45:00	1.4
@@ -1,4 +1,4 @@
-!standard B.01.00      (01)                            04-02-29  AI95-00329/02
+!standard B.01.00      (01)                            04-03-01  AI95-00329/03
 !standard 11.04.01     (04)
 !standard 11.04.01     (05)
 !class amendment 03-03-04
@@ -10,19 +10,15 @@
 
 !summary
 
-We propose to standardize a pragma "No_Return" defined in GNAT and probably
-other Ada95 compilers that specifies that a procedure never
+Pragma No_Return specifies that a procedure never
 returns "normally" but rather always propagates an exception,
 or results in an abort of the calling task.
 
-Additional option: define two new procedures
-in Ada.Exceptions, Always_Raise_Exception and
-Always_Reraise_Occurrence, to which this new
-pragma would apply.
+Ada.Exceptions.Raise_Exception is changed to always raise an exception,
+and has pragma No_Return apply to it. If Raise_Exception is passed
+Null_Id, it raises Constraint_Error, like several of the other operations
+in Ada.Exceptions.
 
-(Or perhaps Ada.Exceptions.No_Return.Raise_Exception
-and Ada.Exceptions.No_Return.Reraise_Occurrence.)
-
 !problem
 
 As Ada compiler and other tools do more static analysis of
@@ -51,16 +47,9 @@
 if the procedure completes normally by reaching the end
 of its body (just as with a function).
 
-Additional option: Add Always_Raise_Exception
-and Always_Reraise_Occurrence to Ada.Exceptions
-(or perhaps a child?) to which pragma No_Return would
-apply. These would raise Constraint_Error if given
-Null_Id or Null_Occurrence, respectively, like several
-of the other routines in Ada.Exceptions.
-
-Alternatively, create a "Ada.Exceptions.No_Return" child
-and add no-return versions of Raise_Exception and
-Reraise_Occurrence there.
+Change the definition of Ada.Exceptions.Raise_Exception
+to raise Constraint_Error of given Null_Id, and mark it
+as a No_Return procedure.
 
 !wording
 
@@ -100,7 +89,6 @@
   [Raise_Exception and] Reraise_Occurrence [have] {has} no effect in the case
   of [Null_Id or] Null_Occurrence.  {Raise_Exception,} Exception_Message, ...
 
-
 !example
 
     procedure Fatal_Error(Msg : String);
@@ -143,7 +131,7 @@
 never return is critical for verifying or simply for
 understanding an algorithm.
 
-GNAT already supports this pragma, and we have recently added it
+GNAT already supports this pragma, and it was recently added it
 to the AdaMagic front end to allow the compiler to do a
 better job of producing warnings in the presence of
 procedures like "Fatal_Error."
@@ -197,45 +185,24 @@
 as well, so the safety provided by the GNAT rule can be preserved
 presuming GNAT users take warnings seriously. (We guess
 they do in that GNAT has a "treat warnings as errors" flag.)
-
-Optional addition:
 
-With this pragma, it would be nice to be able to apply it
-to Ada.Exceptions.Raise_Exception and Reraise_Occurrence.
-However, these existing procedures have no effect if given
-Null_Id or Null_Occurrence, respectively.
-
-It might be desirable to change this, but upward
-compatibility argues for defining new procedures.
-Something like Always_Raise_Exception or Always_Reraise_Occurrence
-(or perhaps Raise_Exception_No_Return) could be added.
-These would be guaranteed to raise some exception, even
-if given Null_Id/Occurrence. To be consistent with
-other subprograms in this package, it would seem best
-to raise Constraint_Error (though Program_Error would
-be another reasonable choice).
-
-If placed in a child, the No_Return aspect could
-be built into the name of the child, thereby allowing
-a "use" clause to give direct visibility on no-return
-versions with the same simple name as before. (Or of
-course local renamings could be used to the same effect.)
-
-Hence an alternative is:
-
-   package Ada.Exceptions.No_Return is
-        procedure Raise_Exception( ... );
-        procedure Reraise_Occurrence( ... );
-   end Ada.Exceptions.No_Return;
-
-
-We have made this pragma apply to Ada.Exceptions.Raise_Exception. This
-requires a (slightly) incompatible change, as Raise_Exception is defined
-in Ada 95 to have no effect if the argument is Null_Id. But this is an
-odd definition - when you call Raise_Exception, you really want it to raise
-an exception. Thus, we've changed it to raise Constraint_Error when passed
-Null_Id.
+Raise_Exception
 
+The existing situation where Raise_Exception has no effect when passed Null_Id
+seems to be of little value. Being able to declare Raise_Exception as a
+No_Return procedure would have significant value, since it is essentially
+always used that way. To be consistent with other subprograms in this package,
+it would seem best to raise Constraint_Error when Raise_Exception is given a
+Null_Id (though Program_Error would be another reasonable choice).
+
+We considered having this pragma apply to Ada.Exceptions.Reraise_Occurrence as
+well. It has no effect when Null_Occurrence is passed, and that would need to
+change in order to apply the pragma. However, it is not unusual to pass the
+occurrence of an exception to other code to delay raising it. If there was no
+exception, passing Null_Occurrence for this works fine. Moreover, as there is
+no test for Null_Occurrence in Ada 95, this is the only way to write such code
+without additional flags. Thus, we considered the incompatibility unacceptable
+for Reraise_Occurrence.
 
 !ACATS test
 
@@ -639,5 +606,86 @@
 if it applies to the expected access type.  So calls via an access
 value of such a type could be assumed to never return.  Not sure
 how useful that would be though.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Sunday, February 29, 2004  11:32 AM
+
+Tucker Taft wrote:
+
+> This version of AI-329 on pragma No_Return has
+> wording, and specifies that Ada.Exceptions.Raise_Exception
+> is No_Return. [Editor's note: That is version /02.]
+
+I really like the AI as written.  If the upward incompatibility gets
+voted down I prefer this alternative:
+
+>   package Ada.Exceptions.No_Return is
+>        procedure Raise_Exception( ... );
+>        procedure Reraise_Occurrence( ... );
+>   end Ada.Exceptions.No_Return;
+>
+Another option might be to do the incompatible change but provide a
+package Ada.Exceptions.Conditional that keeps the current behavior.  (Or
+even call it Ada.ExceptionsPossibly_Return. ;-)  Users wh really need
+the current behavior can use a one-line if statement as a wrapper  And
+that if makes it explicit that the programmer is mixing both return and
+no return behavior.
+
+****************************************************************
+
+From: Arnaud Charlet
+Sent: Monday, March  1, 2004  8:43 AM
+
+A minor comment: GNAT already defines for internal
+usage (in the private part since it's not yet part of the RM) the procedures
+Raise_Exception_Always and Reraise_Occurrence_Always.
+
+Are there any reasons to prefer Always_xxx rather than xxx_Always ?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, March  1, 2004  5:13 PM
+
+I prefer the suffix forms, since then they alphebetize in a consistent
+manner.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, March  1, 2004 6:31 PM
+
+I am inclined to bite the bullet and accept the incompatibility
+here. I suspect that programs that would be affected may well
+have a bug anyway :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, March  1, 2004  7:42 PM
+
+Sorry, I realize the summary/proposal were not
+updated to correspond to the wording section.
+The wording has been defined to make Raise_Exception
+always raise an exception, and to leave Reraise_Occurrence
+as it is.  This seemed to be the consensus of the
+review last time, if I remembered it correctly.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March  1, 2004  7:42 PM
+
+That's the way I remembered it. We decided to have the (slight)
+incompatibility.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March  1, 2004  8:04 PM
+
+No problem, I just posted version /03 that solves this problem.
 
 ****************************************************************