CVS difference for ai05s/ai05-0290-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0290-1.txt

--- ai05s/ai05-0290-1.txt	2012/02/16 04:07:35	1.1
+++ ai05s/ai05-0290-1.txt	2012/02/19 03:34:30	1.2
@@ -1,4 +1,4 @@
-!standard  3.2.4(0)                               12-02-15    AI05-0290-1/01
+!standard  3.2.4(0)                               12-02-18    AI05-0290-1/02
 !standard  7.3.2(0)
 !class Amendment 12-02-14
 !status Amendment 2012 12-02-14
@@ -109,7 +109,49 @@
     body and are immune to optimization. That's why the original proposal
     is preferred (the cost doesn't change when checks are turned off).
 
+Proposal #5: There is an optional "exception" clause on predicates and
+    preconditions. This specifies the exception that will be raised on the
+    failure of the check.
+
+Reason: We want to encourage the conversion of comments to
+    predicates/preconditions in existing libraries. However, changing the
+    exception raised may be an unacceptable incompatibility. By allowing
+    the exception to be raised to be specified, the specification can remain
+    unchanged while additional information is given to tools.
+
+=====================
+
+Since this AI was created, a number of additional issues/proposals have been
+made in e-mail. Since these proposals provide possible solutions for some of
+the issues described above, they're briefly outlined here. (Note that these are
+all related.)
+
+Issue #1: All assertions are described as "checks" other than subtype
+predicates. This should be normalized (they call should be checks, or none
+should).
+
+Issue #2: If these are checks, should pragma Suppress work on them? If so,
+Suppress(All_Checks) should suppress assertions. Tucker reports that Sofcheck
+derived compilers always have worked this way (but there is an incompatibility
+for pragma Assert if it did not do so in the past).
+
+Issue #3: If these are checks, should there be check names for assertions
+(as a group, or individually, or both)? Note that having such control and
+individual check names would solve the problems that Proposals #3 and #4 are
+intended to solve (because pragma Unsuppress would serve the needed purpose
+for #4, and Suppress(Post_Check) and the like would provide the effect of #3.
+
+Issue #4: If suppress acts on assertions, can that a failed but unchecked
+assertion make the program erroneous? (The answer appears to be no.)
+
+Issue #5: How does suppress interact with Assertion_Policy? In particular,
+can Assertion_Policy override Suppress (one hopes not, or the solution
+to Proposal #4 goes away). Perhaps Assertion_Policy Ignore should be considered
+equivalent to Suppress (All_Assertion_Checks).
 
+Issue #6: Suppress is a "permission" to not check, while Assertion_Policy is
+a "requirement" to not check. The Suppress mechanism is more attractive.
+
 !wording
 
 ** TBD **
@@ -181,6 +223,33 @@
     documentation than comments can, it would be unfortunate to discourage
     their use by a segment of the programming population.
 
+For #5:
+Example: Imagine the following routine in GUI library:
+
+    procedure Show_Window (Window : in out Root_Window);
+       -- Shows the window.
+       -- Raises Not_Valid_Error if Window is not valid.
+
+We would like to be able to use a predicate to check the comment. With the
+"exception" clause we can do this without changing the semantics:
+
+    subtype Valid_Root_Window is Root_Window
+       with Dynamic_Predicate =>
+           Is_Valid (Valid_Root_Window) exception Not_Valid_Error;
+
+    procedure Show_Window (Window : in out Valid_Root_Window);
+       -- Shows the window.
+
+If we didn't have the "exception" clause here, using the predicate would
+change the exception raised on this failure. That could cause the exception
+to fall into a different handler than currently, which is likely to not be
+acceptable.
+
+Similarly, the various Containers packages in Ada could use predicates in
+this way to make some of the needed checks; but that can only be done if the
+semantics remains unchanged (raising Program_Error and Constraint_Error,
+not Assertion_Error).
+
 !ACATS Test
 
 Create an ACATS C-Test to test these changes.
@@ -2696,3 +2765,922 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Sent: Wednesday, February 15, 2012  10:50 PM
+
+[Responding to old editorial review comments, the quotes are from Bob Duff.]
+
+> I don't see any problem with 4.6(51/3) and 4.6(57).  "Checks"
+> are the things controlled by pragma Suppress.  We decided that
+> predicates are controlled by assertion policy, so they can't be
+> checks.
+
+That's a *big* problem, because preconditions and the like are most certainly
+described as "checks" (see, for example, the Dynamic Semantics section of
+6.1.1). And trying to describe them as something else is very difficult (in
+terms of wording). The wording of 4.6(51/3) and 4.6(57) is an example of how
+confusing this is.
+
+I would prefer to call these things "checks" (because they are), and then exempt
+checks controlled by Assertion_Policy (that is, checks caused by assertions)
+from Suppress. That shouldn't take many words in 11.5. (Of course, it would be
+even better to allow these to be controlled by Suppress as well as
+Assertion_Policy. But that seems like more change than we'd like to make now. Of
+course, that would provide a solution to the AI05-0290-1 problems of assertion
+control, in particular the availability of Unsuppress. But I digress...)
+
+> (I don't entirely agree with that decision, but it's not important.)
+> So
+> 4.6(51/3) correctly avoids "check" for the predicate.  And
+> 4.6(57) correctly says that checks raise P_E or C_E.  An AARM note
+> could mention that a predicate failure could raise A_E, but isn't
+> mentioned because it isn't a check.
+
+That's what I did for now, but essentially all of the other assertions are
+described as checks. It's just too complicated to invent an entire new language
+and semantics just for them. If we have to change that, I think we're adding a
+month of work to the Standard, because every line of dynamic semantics for
+assertions will have to be totally rewritten. And it took us dozens of
+iterations to get them right as it is (IF they're right).
+
+> But now I think 4.9(34/3) needs to say:
+>
+>     The expression is illegal if its evaluation raises an exception.
+>     For the purposes of this evaluation, the assertion policy is assumed
+>     to be Check.
+>
+> As I said above, if "evaluation" can happen at compile time, then so
+> can "raising".
+
+I'm still dubious, but I think it is irrelevant because assertions are surely
+"checks".
+
+Thoughts?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 16, 2012  5:18 AM
+
+> That's a *big* problem, ...
+
+Please don't panic!
+The only big problem is that the RM is too big.  ;-)
+
+>...because preconditions and the like are most  certainly described as
+>"checks" (see, for example, the Dynamic Semantics  section of 6.1.1).
+
+I see.  I didn't realize that, so I wrote the predicates section thinking that
+assertions are not checks.  Nobody seemed to care at the time, so let's not get
+too excited.  This is what happens when we make the RM too big for one person to
+read cover to cover; we have to live with it now.
+
+>...And trying to describe them as something else is very  difficult (in
+>terms of wording). The wording of 4.6(51/3) and 4.6(57) is an  example
+>of how confusing this is.
+>
+> I would prefer to call these things "checks" (because they are), and
+> then exempt checks controlled by Assertion_Policy (that is, checks
+> caused by assertions) from Suppress.
+
+OK, if you think that's easier, I'm all for it.  Certainly assertions are
+checks, intuitively speaking.
+
+>...That shouldn't take many words
+> in 11.5.
+
+Good.
+
+>...(Of course, it would be even better to allow these to be controlled
+>by Suppress as well as Assertion_Policy. But that seems like more
+>change  than we'd like to make now. Of course, that would provide a
+>solution to the
+> AI05-0290-1 problems of assertion control, in particular the
+>availability of  Unsuppress. But I digress...)
+
+Yeah, it's a bit of a mess that we have two completely different ways of
+suppressing check-like things.  But I agree with not trying to fix that now.
+
+Just yesterday I was discussing a compiler bug with Ed Schonberg, which involved
+something like "expand this node with all checks suppressed", and the bug was
+that assertions were NOT being suppressed, but they needed to be.
+
+> > (I don't entirely agree with that decision, but it's not important.)
+> > So
+> > 4.6(51/3) correctly avoids "check" for the predicate.  And
+> > 4.6(57) correctly says that checks raise P_E or C_E.  An AARM note
+> > could mention that a predicate failure could raise A_E, but isn't
+> > mentioned because it isn't a check.
+>
+> That's what I did for now, but essentially all of the other assertions
+> are described as checks. It's just too complicated to invent an entire
+> new language and semantics just for them. If we have to change that, I
+> think we're adding a month of work to the Standard, because every line
+> of dynamic semantics for assertions will have to be totally rewritten.
+> And it took us dozens of iterations to get them right as it is (IF they're
+< right).
+
+Well, I suppose they're not right, but they're close enough.
+
+> > But now I think 4.9(34/3) needs to say:
+> >
+> >     The expression is illegal if its evaluation raises an exception.
+> >     For the purposes of this evaluation, the assertion policy is assumed
+> >     to be Check.
+> >
+> > As I said above, if "evaluation" can happen at compile time, then so
+> > can "raising".
+>
+> I'm still dubious, but I think it is irrelevant because assertions are
+> surely "checks".
+
+OK.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 16, 2012  8:00 AM
+
+I believe (pretty strongly) that Suppress(All_Checks) ought to suppress
+assertion checks as well.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 16, 2012  8:10 AM
+
+I could be convinced of that, but:
+
+You don't give any reasons for your pretty-strong belief.
+
+We've discussed this, and that's not what we decided.
+If we had gone that way, then why would we have invented Assertion_Policy?  It
+would make much more sense to have added some new check names.
+
+If we went that way, and the program executes "pragma Assert(False);", and
+assertion checks (or all checks) are suppressed, then is it erroneous?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 16, 2012  8:28 AM
+
+> I could be convinced of that, but:
+>
+> You don't give any reasons for your pretty-strong belief.
+
+There are a lot of programs that use Suppress(All_Checks) to mean "turn off all
+run-time checks" and as we seem to now agree, assertion checks are "checks."
+
+> We've discussed this, and that's not what we decided.
+
+I must have misssed or slept through the discussion on All_Checks as applied to
+assertion checks.
+
+> If we had gone that way, then why would we have invented
+> Assertion_Policy?  It would make much more sense to have added some
+> new check names.
+
+Assertion policy was invented because there was more than just "on" or "off" for
+assertions.  We imagined "assume true," "ignore," "check", and "check fiercely,"
+etc.
+
+> If we went that way, and the program executes "pragma Assert(False);",
+> and assertion checks (or all checks) are suppressed, then is it
+> erroneous?
+
+I was in the discussion where we decided that when assertion are ignored, they
+are really ignored.  It is as though they weren't there at all.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 16, 2012  8:33 AM
+
+...
+> I could be convinced of that, but:
+>
+> You don't give any reasons for your pretty-strong belief.
+
+The other reason is the wording in 11.5 about All_Checks:
+
+[The following check corresponds to all situations in which any predefined
+exception is raised.]
+
+25
+All_Checks
+
+Represents the union of all checks; [suppressing All_Checks suppresses all
+checks.]
+
+25.a
+Ramification: All_Checks includes both language-defined and
+implementation-defined checks.
+
+25.b/3
+To be honest: {AI05-0005-1} There are additional checks defined in various
+Specialized Needs Annexes that are not listed here. Nevertheless, they are
+included in All_Checks and named in a Suppress pragma on implementations that
+support the relevant annex. Look up "check, language-defined" in the index to
+find the complete list.
+
+---
+
+This certainly conveys to me the message that Suppress(All_Checks) suppresses
+all checks, whether or not we have a "named" check associated with them.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 16, 2012  1:28 PM
+
+> I believe (pretty strongly) that Suppress(All_Checks) ought to
+> suppress assertion checks as well.
+
+This from the guy who insisted up and down that suppression was the wrong model
+for assertions. :-)
+
+I actually don't know how to reconcile that with Assertion_Policy(Ignore).
+Suppress(All_Checks) makes the program erroneous if checks fail;
+Assertion_Policy(Ignore) doesn't.
+
+The cool thing is that if this is true, we only need to add a user Note to 11.5:
+"Assertions are checks, so they're suppressed by Suppress(All_Checks). We don't
+give them a check name, since using Assertion_Policy is preferred if it is
+desired to turn off assertions only." (This is too important for just an AARM
+note.)
+
+And reword a few things so that predicates are described as checks.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 16, 2012  1:49 PM
+
+> The other reason is the wording in 11.5 about All_Checks:
+>
+> [The following check corresponds to all situations in which any
+> predefined exception is raised.]
+>
+> Represents the union of all checks; [suppressing All_Checks suppresses
+> all checks.]
+
+Assertion_Error is not a predefined exception.  So if you want Suppress to
+suppress assertions, we need new wording somewhere.
+
+Most of the above text is @Redundant.  If you want "the union of all checks" to
+make sense for assertions, then I think the assertions need check name(s).
+
+And from your other email, I assume you're proposing to change this:
+
+  26  If a given check has been suppressed, and the corresponding error
+  situation occurs, the execution of the program is erroneous.
+
+although that wasn't 100% clear to me.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 16, 2012  1:54 PM
+
+> I actually don't know how to reconcile that with Assertion_Policy(Ignore).
+> Suppress(All_Checks) makes the program erroneous if checks fail;
+> Assertion_Policy(Ignore) doesn't.
+
+Assertion checks are user-specified, and so there is no reason for execution to
+become erroneous if they are suppressed, so long as it is interpreted as meaning
+the same thing as ignored.  Other kinds of checks, such as array out of bounds,
+null pointer, discriminant checks, etc., clearly make the execution erroneous if
+they fail and execution proceeds.
+
+Assertion policy was created to allow for more implementation flexibility
+through the use of implementation-defined policies.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, February 16, 2012  1:51 PM
+
+>> I believe (pretty strongly) that Suppress(All_Checks) ought to
+>> suppress assertion checks as well.
+>
+> This from the guy who insisted up and down that suppression was the
+> wrong model for assertions. :-)
+
+I think this means that we want to make it clear that a suppressing an assertion
+check cannot lead to erroneousness in the same way that suppressing other kinds
+of checks can.
+
+It doesn't make sense to try to define the behavior of a program execution
+which, absent suppression, would have failed an array indexing  check. That's
+why such an execution is ,quite correctly, defined to be erroneous.
+
+Assertion checks are different - type-safety and all the other invariants that
+an implementation (as opposed to a user) might depend on are not compromised if
+we ignore assertion checks. If we say that a suppressed assertion check simply
+might or might not be performed, this doesn't lead to definitional problems.
+
+Presumably suppressing an assertion check (when the assertion policy is Check)
+means that an implementation is allowed, but not required, to behave as though
+the assertion policy in effect is Ignore (which, incidentally, includes
+evaluation of the Boolean expression).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 16, 2012  2:04 PM
+
+> Assertion_Error is not a predefined exception.  So if you want
+> Suppress to suppress assertions, we need new wording somewhere.
+>
+> Most of the above text is @Redundant.  If you want "the union of all
+> checks" to make sense for assertions, then I think the assertions need
+> check name(s).
+
+I'm not sure I would agree that if something is a "check" then it automatically
+needs a "check name."
+
+> And from your other email, I assume you're proposing to change this:
+>
+>    26  If a given check has been suppressed, and the corresponding error
+>    situation occurs, the execution of the program is erroneous.
+>
+> although that wasn't 100% clear to me.
+
+Yes, as mentioned in an earlier note, suppressing an assertion check would mean
+ignoring it, not presuming it was true.
+
+I gave my reasons why I think All_Checks should cover assertion checks.  I'd be
+curious how others feel.  When someone says "suppress all" I have always assumed
+they really meant it. The creation of Assertion_Policy was to give more
+flexibility, but I never thought it meant making "suppress all" mean "suppress
+some."  Maybe I am the only person who feels this way...
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Thursday, February 16, 2012  2:07 PM
+
+> Assertion policy was created to allow for more implementation
+> flexibility through the use of implementation-defined policies.
+
+Indeed, but I'm afraid it's not flexible enough because it's a configuration
+pragma, while Suppress gives you a per-scope  control.  Could we just make it
+into a regular pragma with similar semantics?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 16, 2012  2:45 PM
+
+...
+> > Most of the above text is @Redundant.  If you want "the union of all
+> > checks" to make sense for assertions, then I think the assertions
+> > need check name(s).
+>
+> I'm not sure I would agree that if something is a "check"
+> then it automatically needs a "check name."
+
+I would hope not, since there are no check names for checks defined in Annexes,
+and there is an AARM note (which someone quoted earlier) that says they're
+included in All_Checks.
+
+> > And from your other email, I assume you're proposing to change this:
+> >
+> >    26  If a given check has been suppressed, and the corresponding error
+> >    situation occurs, the execution of the program is erroneous.
+> >
+> > although that wasn't 100% clear to me.
+>
+> Yes, as mentioned in an earlier note, suppressing an assertion check
+> would mean ignoring it, not presuming it was true.
+
+Could you suggest a wording for this paragraph that would have the right effect?
+
+> I gave my reasons why I think All_Checks should cover assertion checks. I'd be
+> curious how others feel.  When someone says "suppress all" I have always
+> assumed they really meant it. The creation of Assertion_Policy was to give
+> more flexibility,
+> but I never thought it meant making "suppress all" mean "suppress some."
+> Maybe I am the only person who feels this way...
+
+I've always thought that Suppress was a better model than Assertion_Policy for
+assertions. I agree that not making them erroneous is probably a good idea. But
+I would much prefer that the implementation be allowed to check any assertions
+that it wants to, even when they are suppressed. (They're supposed to be true,
+after all.) Presumably, an implementation would only check those that it could
+then prove to be true or are very cheap. "Ignore" does not let the
+implementation have any flexibility in this area.
+
+OTOH, making Suppress(All_Checks) apply to assertions might be a (minor)
+compatibility problem. pragma Assert would be included in that, and it probably
+isn't included in Ada 2005 compilers. Thus it could be turned off where it is
+now on. Not a big deal, but we ought to remain aware of it.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 16, 2012  2:51 PM
+
+>>	Assertion policy was created to allow for more implementation
+>>	flexibility through the use of implementation-defined policies.
+>>
+>	Indeed, but I'm afraid it's not flexible enough because it's a
+>configuration pragma, while Suppress gives you a per-scope  control.
+> Could we just make it into a regular pragma with similar semantics?
+
+I forgot about that; it had come up in the write-up of AI05-0290-1 I did
+yesterday.
+
+If we gave these check names, at least some of the control issues would go away,
+because Unsuppress would do what Erhard and I have been asking for (give a way
+for a library to force predicate and precondition checks always).
+
+As noted in my previous note, Suppress is better than Ignore because it allows
+the compiler to make the check and then depend on it later (presumably it would
+only do that if the net code size was smaller). That eliminates some of the need
+for other policies.
+
+So perhaps much of what we really want could be accomplished by mostly
+abandoning Assertion_Policy, and using Suppress, modulo that it is not erroneous
+to fail an unchecked assertion.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 16, 2012  2:58 PM
+
+>>> And from your other email, I assume you're proposing to change this:
+>>>
+>>>     26  If a given check has been suppressed, and the corresponding error
+>>>     situation occurs, the execution of the program is erroneous.
+>>>
+>>> although that wasn't 100% clear to me.
+>>
+>> Yes, as mentioned in an earlier note, suppressing an assertion check
+>> would mean ignoring it, not presuming it was true.
+>
+> Could you suggest a wording for this paragraph that would have the
+> right effect?
+
+How about:
+
+If a given check has been suppressed, then if it is an assertion check, the
+corresponding assertion is simply ignored, while if it is some other check and
+the corresponding error situation occurs, the execution of the program is
+erroneous.
+
+>> I gave my reasons why I think All_Checks should cover assertion checks. I'd be
+>> curious how others feel.  When someone says "suppress all" I have
+>> always assumed
+>> they really meant it. The creation of Assertion_Policy was to give
+>> more flexibility,
+>> but I never thought it meant making "suppress all" mean "suppress some."
+>> Maybe I am the only person who feels this way...
+>
+> I've always thought that Suppress was a better model than
+> Assertion_Policy for assertions. I agree that not making them
+> erroneous is probably a good idea. But I would much prefer that the
+> implementation be allowed to check any assertions that it wants to,
+> even when they are suppressed. (They're supposed to be true, after
+> all.) Presumably, an implementation would only check those that it could then prove to be true or are very cheap. "Ignore"
+> does not let the implementation have any flexibility in this area.
+>
+> OTOH, making Suppress(All_Checks) apply to assertions might be a
+> (minor) compatibility problem. pragma Assert would be included in
+> that, and it probably isn't included in Ada 2005 compilers. Thus it
+> could be turned off where it is now on. Not a big deal, but we ought to remain aware of it.
+
+Pragma Assert was in plenty of Ada 95 compilers as well.
+I'd be curious how it was implemented there.  Certainly in Green Hills and Aonix
+compilers I can assure you that Suppress(All_Checks) turned off assertion checks
+as well.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, February 16, 2012  3:10 PM
+
+> If a given check has been suppressed, then if it is an assertion
+> check, the corresponding assertion is simply ignored, while if it is
+> some other check and the corresponding error situation occurs, the
+> execution of the program is erroneous.
+
+Although I agree with the general direction you are suggesting, I see two minor
+problems with this wording.
+
+    1) For Assertion_Policy Ignore, we still evaluate the Boolean.
+       I don't think we want something similar but slightly different
+       here.
+
+    2) I want to preserve the longstanding rule that suppression only
+       gives an implementation additional permissions - it never imposes
+       a requirement on an implementation. It sounds like you are
+       requiring that the assertion must be ignored, as opposed to
+       allowing it to be ignored.
+
+I'll try to come up with wording that addresses these points.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 16, 2012  3:25 PM
+
+>     1) For Assertion_Policy Ignore, we still evaluate the Boolean.
+>        I don't think we want something similar but slightly different
+>        here.
+
+Huh? When the policy is Ignore, nothing is evaluated. Nor can anything be
+assumed. It wouldn't be very useful if it evaluated something.
+
+>     2) I want to preserve the longstanding rule that suppression only
+>        gives an implementation additional permissions - it never imposes
+>        a requirement on an implementation. It sounds like you are
+>        requiring that the assertion must be ignored, as opposed to
+>        allowing it to be ignored.
+
+Definitely. I consider that an advantage rather than a "difference".
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 16, 2012  3:32 PM
+
+> Although I agree with the general direction you are suggesting, I see
+> two minor problems with this wording.
+>
+> 1) For Assertion_Policy Ignore, we still evaluate the Boolean.
+> I don't think we want something similar but slightly different here.
+
+I had forgotten that, and I doubt if all Ada 95 compilers follow that rule, and
+it would really defeat the purpose of ignoring the assertion from a performance
+point of view. Where is that specified?
+
+> 2) I want to preserve the longstanding rule that suppression only
+> gives an implementation additional permissions - it never imposes a
+> requirement on an implementation. It sounds like you are requiring
+> that the assertion must be ignored, as opposed to allowing it to be
+> ignored.
+
+I suppose, but then it must either check or ignore.
+It can't suppress the check and then assume it is true.
+One of the fundamental principles that got us to the Assertion_Policy approach
+was that adding a pragma Assert never made the program *less* safe because it
+was asserting something that was in fact untrue.
+
+>
+> I'll try to come up with wording that addresses these points.
+
+All power to you.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 16, 2012  3:53 PM
+
+...
+> > 1) For Assertion_Policy Ignore, we still evaluate the Boolean.
+> > I don't think we want something similar but slightly different here.
+>
+> I had forgotten that, and I doubt if all Ada 95 compilers follow that
+> rule, and it would really defeat the purpose of ignoring the assertion
+> from a performance point of view.
+> Where is that specified?
+
+I don't think you forgot anything, I think Steve is making this up.
+
+> > 2) I want to preserve the longstanding rule that suppression only
+> > gives an implementation additional permissions - it never imposes a
+> > requirement on an implementation. It sounds like you are requiring
+> > that the assertion must be ignored, as opposed to allowing it to be
+> > ignored.
+>
+> I suppose, but then it must either check or ignore.
+> It can't suppress the check and then assume it is true.
+> One of the fundamental principles that got us to the Assertion_Policy
+> approach was that adding a pragma Assert never made the program *less*
+> safe because it was asserting something that was in fact untrue.
+
+Right, this is a general principle in Ada. But of course "check" doesn't mean
+that any code will actually be executed: such a check might be optimized out.
+For instance:
+
+      procedure P (A : access Something)
+          with Pre => A /= null;
+
+Ignoring the fact that the programmer should probably have used a null
+exclusion, if a call looks like:
+
+       if Ptr /= null then
+            P (Ptr);
+
+The check would also be Ptr /= null. One would expect that normal
+common-subexpression and dead code elimination would completely remove the
+check. But it still can be assumed true in the body in this case.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, February 16, 2012  3:54 PM
+
+> I'll try to come up with wording that addresses these points.
+
+1) Add Assertion_Check to the list of defined checks (details TBD)
+
+2) Replace "check" with "check other than Assertion_Check" in
+    the erroneous execution section of 11.5.
+
+3) In the Implementation Permissions section, add
+
+    At any point within a region for which Assertion_Check
+    is suppressed, an implementation is allowed (but not required)
+    to define the Assertion_Policy in effect at that point to
+    be Ignore.
+
+> Huh? When the policy is Ignore, nothing is evaluated. Nor can anything
+> be assumed.
+
+Oops. My mistake.
+The RM does contain
+
+    If the assertion policy is Ignore at the point of a pragma Assert,
+    ...the elaboration of the pragma consists of evaluating the boolean
+    expression ...
+
+but the elided text is significant. My bad.
+
+Nonetheless, I still think that defining the effect of suppression in terms of
+the Ignore policy is a good idea.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 16, 2012  5:29 PM
+
+> Assertion checks are user-specified, and so there is no reason for
+> execution to become erroneous if they are suppressed,...
+
+Not sure what "no reason" means.  Yeah, there is no reason why we MUST define a
+suppressed False assertion to be erroneous. But there is a reason that there
+ought to be a mode where it's erroneous: efficiency.  Currently, that's done via
+an impl-def policy.  There are lots of cases where efficiency can be improved by
+assuming (and not checking) that assertions are True.
+
+>...so long as it is interpreted as meaning  the same thing as ignored.
+
+That part is circular reasoning: yes, of course if we define it like "Ignore"
+then it's not erroneous.
+
+>...Other kinds of checks,
+> such as array out of bounds, null pointer, discriminant  checks, etc.,
+>clearly make the execution erroneous if  they fail and execution
+>proceeds.
+
+On the flip side, there are non-assertion checks that could sensibly have an
+"ignore" option.  Range checks, for example: don't check the range, but don't
+later assume it's in range. Overflow checks: don't check, but return an
+implementation dependent value of the type.  Robert is fond of pointing out
+that:
+
+    pragma Suppress(...);
+    if X = 0 then
+        Put_Line(...);
+    end if;
+    Y := 1/X;
+
+most programmers are surprised that the compiler can completely eliminate the if
+statement.
+
+> Assertion policy was created to allow for more implementation
+> flexibility through the use of implementation-defined policies.
+
+Right, but it's a bit of a mess.
+It's not clear why more flexibility isn't desirable for non-assertion checks.
+
+> > The cool thing is that if this is true, we only need to add a user
+> > Note to
+> > 11.5: "Assertions are checks, so they're suppressed by Suppress(All_Checks).
+> > We don't give them a check name, since using Assertion_Policy is
+> > preferred if it is desired to turn off assertions only." (This is
+> > too important for just an AARM note.)
+> >
+> > And reword a few things so that predicates are described as checks.
+
+Right, if assertions are checks, we really should be using the standard wording
+for checks: "a check is made...".  Currently we say "If the policy is Check,
+then ... Assertion_Error is raised", which is weird, because we don't say "if
+Divide_Check is not suppressed, a check is made that ... is nonzero".
+
+It would simplify if the assertion-check wording assumed that the policy is
+Check.  Then when we define Assertion_Policy, we say, "Wording elsewhere assumes
+... Check.  If the policy is Ignore, then instead ...".
+
+I fear we don't have the time to do all this rewording.
+Oh, well, it's not the end of the world if we're inconsistent.
+
+> I'm not sure I would agree that if something is a "check" then it
+> automatically needs a "check name."
+
+I think the intent was that all checks have names.  But the ones in the annexes
+are only named via a "To be honest".  That's a cheat, of course.
+
+> Yes, as mentioned in an earlier note, suppressing an assertion check
+> would mean ignoring it, not presuming it was true.
+
+I'm a little uncomfortable with the idea that Suppress wouldn't mean
+"erroneous".
+
+I'm a little uncomfortable that:
+
+    subtype S is Natural range 0..10;
+
+has confusingly different semantics than:
+
+    subtype S is Natural with
+        Static_Predicate => S <= 10;
+
+> I gave my reasons why I think All_Checks should cover assertion
+> checks.  I'd be curious how others feel.
+
+I have mixed feelings.
+
+> ...When someone
+> says "suppress all" I have always assumed they really meant it.
+
+Yeah, but to me, "really mean it" means "cross my heart and hope to die, you may
+strike me with erroneous lightning if I'm wrong".  In other words, Suppress is
+the extreme, "prefer efficiency over safety".
+
+> The creation of Assertion_Policy was to give more flexibility, but I
+> never thought it meant making "suppress all" mean "suppress some."
+> Maybe I am the only person who feels this way...
+
+I see your point.  Mixed feelings.
+
+> > 1) For Assertion_Policy Ignore, we still evaluate the Boolean.
+> > I don't think we want something similar but slightly different here.
+>
+> I had forgotten that, ...
+
+Please re-forget that.  ;-)
+
+> One of the fundamental principles that got us to the Assertion_Policy
+> approach was that adding a pragma Assert never made the program *less*
+> safe because it was asserting
+  ^^^^^
+> something that was in fact untrue.
+
+No, "never" is wrong.  The principle holds for Check and Ignore policies, but
+implementations can have a policy where the principle is violated -- and such a
+policy has some advantage.
+
+> 1) Add Assertion_Check to the list of defined checks (details TBD)
+
+I'd prefer to split out Precondition_Check, Postcondition_Check,
+Predicate_Check, Invariant_Check, Assert_Check (Pragma_Assert_Check?).
+Assertion_Check could be the union of these. Predicate_Check could be the union
+of Static_Predicate_Check and Dynamic_Predicate_Check.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 16, 2012  6:17 PM
+
+...
+> Steve Baird wrote:
+> > 1) Add Assertion_Check to the list of defined checks (details TBD)
+>
+> I'd prefer to split out Precondition_Check, Postcondition_Check,
+> Predicate_Check, Invariant_Check, Assert_Check (Pragma_Assert_Check?).
+> Assertion_Check could be the union of these.
+> Predicate_Check could be the union of Static_Predicate_Check and
+> Dynamic_Predicate_Check.
+
+And something like Before_Call_Assertion_Check is the union of Predicate_Check
+and Precondition_Check (I don't have the perfect name); and
+After_Call_Assertion_Check is the union of Postcondition_Check and
+Invariant_Check.
+
+In any case, this is definitely getting into AI05-0290-1 territory ("Improved
+control for assertions"), and there is not enough time to come to any
+conclusions before the agenda is finalized (that's tomorrow), so I think I'll
+probably just add all of this to that AI and we'll have to hash it out at the
+meeting.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 16, 2012  6:33 PM
+
+> I'll probably just add all of this to that AI and we'll have to hash
+> it out at the meeting.
+
+OK.  Or, we can hash it out between 2013 and 2020.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 16, 2012  6:59 PM
+
+> OK.  Or, we can hash it out between 2013 and 2020.
+
+I don't think that works, at least for Suppress(All_Checks), because changing
+that later would be a massive incompatibility. (It already might be an
+incompatibility, but not with Tucker's compilers.)
+
+Similarly, we've had several strong comments that we need mechanisms for
+3rd-party packages. That shouldn't be ignored.
+
+Once we've dealt with those two, it seems inconceivable that we couldn't agree
+on the rest (which seems easy to me). In any case, I hope we don't spend the
+whole meeting on things that no one will ever notice (this is definitely *not*
+in that category).
+
+****************************************************************
+
+From: Erhard  Ploedereder
+Sent: Friday, February 17, 2012  3:49 AM
+
+>> I believe (pretty strongly) that Suppress(All_Checks) ought to
+>> suppress assertion checks as well.
+
+> The cool thing is that if this is true, we only need to add a user
+> Note to
+> 11.5: "Assertions are checks, so they're suppressed by Suppress(All_Checks).
+> We don't give them a check name, since using Assertion_Policy is
+> preferred if it is desired to turn off assertions only." (This is too
+> important for just an AARM note.)
+
+And the semantics of
+ pragma Unsuppress(All_Checks);
+ pragma Assertion_Policy(Ignore);
+
+is what ? Obviously there needs to be a rule to resolve the apparent
+contradiction.
+
+Incidently:
+The point that "the old checks" prevent erroneousness within the framework of
+language semantics while assertion checks are unrelated to erroneousness but
+rather deal with application semantics is a very good one. We ought to keep that
+in mind when deciding on assertion control.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Friday, February 17, 2012  4:12 AM
+
+John's book says "pragma Suppress (All_Checks); which does the obvious thing".
+
+So it's not so obvious.
+
+What would people naturally reply if asked what it
+covers, without thinking too much? As the Assertion_Policy is called "Check" and
+not something like "Verify" my top-of-my-head answer  would be that assertions
+are checks.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Friday, February 17, 2012  4:29 AM
+
+>> OK.  Or, we can hash it out between 2013 and 2020.
+> I don't think that works, at least for Suppress(All_Checks), because
+> changing that later would be a massive incompatibility.
+
+I agree with Randy. This is way too important to not resolve now.
+and I want to expand the future incompatibility argument to the Assertion
+control in general.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Friday, February 17, 2012  5:06 AM
+
+If pragma Assertion_Policy(Ignore) "guarantees" that the assertion is not
+evaluated, then there is no check to be talked about, is there?
+Consequently
+ pragma Unsuppress(All_Checks);
+ pragma Assertion_Policy(Ignore);
+would imply that there is nothing there to be unsuppressed, hence Unsuppress
+would not be an answer to the 3rd party-SW question.
+
+In the end, I propose to make the Assertion Control pragmas semantically
+analogous to the Suppress/Unsuppress pragmas (including the scoping), but
+controlling only the assertion world. The syntactic differences are there only
+to separate assertion checks from runtime checks that prevent erroneousness.
+(Maybe it would be a good idea to have the assertion check names as 2. argument
+to assertion control pragmas only, with "All_Checks" as a special comprehensive
+choice on the Suppress side.)
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, February 17, 2012  1:26 PM
+
+> John's book says "pragma Suppress (All_Checks); which does the obvious thing".
+
+> So it's not so obvious.
+
+It was obvious when I wrote it!
+
+****************************************************************

Questions? Ask the ACAA Technical Agent