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

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

--- ai05s/ai05-0290-1.txt	2012/04/28 05:10:22	1.10
+++ ai05s/ai05-0290-1.txt	2012/05/12 03:06:59	1.11
@@ -7042,3 +7042,4128 @@
 is useful, then implementations can add it.
 
 ****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 6, 2012  8:45 AM
+
+A general thought here. I don't think we are going to be able to get all this
+stuff 100% right first time. I especially don't think that a bunch of language
+designers within minimal experience in writing large Ada systems using a
+contract approach are going to be able to resolve this in a week or two of
+hurried email dicussion.
+
+Whatever we decide probably doesn't matter than much, since it will be subject
+to refinement on use.
+
+I definitely would like to get the input of users who DO have the experience of
+writing large Ada systems using preconditions and postconditions (remember GNAT
+has had these capabilities for a couple of years, and that those pragmas were
+added to support some large scale customers writing critical systems, some of
+the certified, who wanted to use a contract based approach).
+
+We definitely will get this input over time, and it may well lead us to modify
+and refine what we have.
+
+That's fine, Ada is an evolving language, and we improve, modify, and refine the
+language all the time.
+
+No need to get too crazy with the attempt to get the Ada 2012 RM perfect first
+time around.
+
+I think we will be nearer to the final result if we choose the constraint model
+for predicats, but I also think it doesn't matter *that* much.
+
+Let's do our best to get the details right, but let's not go crazy over it
+(talking about delaying till 2014 is to me in the crazy category :-) :-))
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, March 6, 2012  9:48 AM
+
+> No need to get too crazy with the attempt to get the Ada 2012 RM
+> perfect first time around.
+
+I agree with that, but still must be careful to not put anything that would
+create incompatibilities to fix later.
+
+F.e., we do have to decide now if we raise Constraint_Error or Assertion_Error
+for failures of subtype predicates.
+
+---
+Now for the straw poll:
+I tend to agree with the position that predicates are "extended constraints".
+There is certainly no problem with static predicates. What worries me is the
+whole notion of dynamic predicates.
+
+I view a type as a set of values, and a subtype as a subset of that set.
+It seems we went that way:
+1) I want a subtype that excludes 0.
+   subtype Not_null is integer with Not_Null /= 0; Fine, static predicate
+
+2) Now, I want only even values. Let's do it the same:
+   subtype Even is Integer with Even mod 2 = 0; Gosh, that's not static.  We
+   have to allow dynamic predicates
+
+3) But now, we have that strange thing:
+   N : Integer := Anything;
+   subtype Strange is Integer with Strange mod N = 0;
+
+Here, the values are not moving, it is the boundaries of the subset that can
+move at any time, putting a value in or out at random!
+
+
+I really think we should concentrate on 1) and 2), making these work as
+expected. Define what happens with 3 for the sake of portability, but don't
+worry if it makes strange things.
+
+And if people remove checks, all bets are off. If you  want something
+guaranteed, write preconditions. I don't buy the argument "I'll make a subtype
+because I need a precondition in various places", that's just saving typing. If
+the subtype makes sense from the  problem domain, fine, otherwise use
+preconditions.
+
+After all, that may even make a clear cut between where to  use predicates or
+preconditions: use preconditions when you want guarantees even when checks are
+suppressed.
+
+Maybe an  implementation advice that /within preconditions/, the compiler should
+not rely on predicates beeing true.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 6, 2012  10:11 AM
+
+> I agree with that, but still must be careful to not put anything that
+> would create incompatibilities to fix later.
+
+Incompatibilities are an issue for implementations, not the standard per se. I
+don't think that is too much of a concern. An implementation can always deal
+with such problems if they are significant, by introducing switches etc.
+
+> F.e., we do have to decide now if we raise Constraint_Error or
+> Assertion_Error for failures of subtype predicates.
+
+Well no big deal, if you change your mind in six months that will have zero
+effect on the the implementations out there. The new release of GNAT Pro that
+would reflect any last minute decisions in the RM won't be out for another 10
+months.
+
+In practice, the bigger compatibility problems are those caused by changes in
+the last few months before the RM is issued, GNAT Pro version 7, which is what
+people will be using for a year, was finalized a couple of months ago, and there
+are some changes.
+
+But not to worry, that's AdaCore's problem, and it's perfectly manageable, it's
+not a problem for the standard.
+
+> 2) Now, I want only even values. Let's do it the same:
+>     subtype Even is Integer with Even mod 2 = 0; Gosh, that's not
+> static.  We have to allow dynamic predicates
+>
+> 3) But now, we have that strange thing:
+>     N : Integer := Anything;
+>     subtype Strange is Integer with Strange mod N = 0;
+>
+> Here, the values are not moving, it is the boundaries of the subset
+> that can move at any time, putting a value in or out at random!
+>
+>
+> I really think we should concentrate on 1) and 2), making these work
+> as expected. Define what happens with 3 for the sake of portability,
+> but don't worry if it makes strange things.
+
+I definitely agree with this
+
+> And if people remove checks, all bets are off. If you  want something
+> guaranteed, write preconditions. I don't buy the argument "I'll make a
+> subtype because I need a precondition in various places", that's just
+> saving typing. If the subtype makes sense from the  problem domain,
+> fine, otherwise use preconditions.
+
+I agree with this
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 6, 2012  10:20 AM
+
+> No need to get too crazy with the attempt to get the Ada 2012 RM
+> perfect first time around.
+
+I agree with everything Robert said, including the parts I snipped.
+
+I'd like to add:  We should avoid adding new stuff now, to maximize the
+probability that we can do it right later, and minimize the amount of
+ill-conceived baggage that might get orphaned when we do it right.  Also to
+minimize the time we need to spend talking about such new features!
+
+Adding Unsuppressable, Force, or the like seems unwise at this time, although
+such things might well be a good idea for a binding interpretation in 2013-14.
+
+Changing invariants to raise Constraint_Error is OK with me to do now.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 6, 2012  10:27 AM
+
+I agree with all the above additions :-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 6, 2012  10:26 AM
+
+> An implementation can always deal with such problems if they are
+> significant, by introducing switches etc.
+
+Right.
+
+Also, note that we don't usually worry TOO much about incompatibilies involving
+incorrect programs (which includes programs that turn off failing checks,
+whether that be "ignore/safe" or "suppress/erroneous").
+
+And note that even Constraint_Error vs. Assertion_Error isn't THAT big of a
+deal, because assertions are primarily for detecting bugs, not for handling and
+recovering from.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, March 6, 2012  12:03 PM
+
+Tiucker Taft wrote:
+> On the other hand, we could perhaps distinguish static and dynamic
+> predicates, and say that the compiler can never assume a dynamic
+> predicate evaluates to true, since we know dynamic predicates are not
+> always well behaved.  On the other hand, a static predicate is pretty
+> well defined, definitely doesn't have any side effects, and is about
+> as equivalent to a range constraint as you can get, so it is well
+> defined to say what it means to assume it is true even without
+> checking it.
+
+This sounds promising to me.
+
+Robert Dewar wrote:
+> I think it is fine to insist on the predicate check not being
+> performed if it is suppressed. After all the only reason we don't
+> insist on the check being suppressed in the constraint case is that it
+> may be infeasible or too expensive to suppress the check (e.g. if it
+> is free in hardware), and that reasoning does not apply to predicates.
+
+No, the only reason we don't insist on the check being suppressed in the
+constraint case is that we don't have well-defined semantics for an execution
+which, for example, "successfully" writes to an out-of-bounds array element
+because the index check was suppressed.
+
+This case is, quite correctly, defined to be erroneous and erroneous means
+anything can happen including performing the suppressed check and raising C_E
+just as if the check had not been suppressed.
+
+However, this supports your main point - "it is fine to insist on the predicate
+check not being performed if it is suppressed" - because omitting an assertion
+check doesn't introduce definitional problems.
+
+Combining Tuck's and Robert's ideas, we get
+
+    -- Suppressing any form of assertion except
+       a static predicate check simply causes the
+       assrtion to be ignored. The implementation is
+       not granted permission to make any extra
+       assumptions -the hypothetical behavior of
+       the execution if the check had been performed
+       is completely irrelevant. A variation on this
+       would be to have suppression grant a permission (as
+       opposed to imposing a requirement) to ignore
+       the assertion.
+
+    - Suppressing a static predicate check is
+      follows the same model as suppressing a
+      constraint check. The implementation is allowed
+      to assume that the check would have passed
+      and execution is erroneous if this assumption
+      turns out to be false.
+
+I could live with this.
+
+In earlier discussions however, there was some support for the idea that we
+don't want adding an assertion to make make a program less reliable - the
+scenario some folks were concerned about is
+     - user adds assertions for improved debugging, etc.
+     - user disables them for the production version
+     - some execution of the production version then becomes
+       erroneous where it otherwise wouldn't have.
+     - some catastrophic failure occurs which wouldn't have
+       occurred if the assertion had never been written
+
+If folks want to avoid this problem, I could also live with eliminating this
+special treatment for static predicates and instead using the "suppression does
+not allow assumptions" approach for all forms of assertions.
+
+Robert Dewar wrote:
+> I don't care, why not say it is a bounded error to have side effects,
+> and the possible effects of a suppressed check is that it might or
+> might not update the global or may set it to some unexpected value.
+
+I agree with the spirit of this remark. As long as we have well-defined
+semantics for suppressing an assertion check, I'm less concerned about the
+details. I just want them to be well-defined.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 6, 2012  12:34 PM
+
+> No, the only reason we don't insist on the check being suppressed in
+> the constraint case is that we don't have well-defined semantics for
+> an execution which, for example, "successfully" writes to an
+> out-of-bounds array element because the index check was suppressed.
+
+That's just not true historically. During the design of Ada 83, this was
+specifically discussed, and it is absolutely the case that the main reason for
+not insisting on the check being suppressed (*) is that on some hardware, e.g.
+MIPS at the time, checking for integer overflow was free, and for quite a few
+machines, checking for float overflow was free.
+
+Since the idea of pragma Suppress was to speed up execution, it was silly to
+require it to suppress no-cost checks!
+
+> This case is, quite correctly, defined to be erroneous and erroneous
+> means anything can happen including performing the suppressed check
+> and raising C_E just as if the check had not been suppressed.
+
+(*) Yes, I know this, but this is language lawyer stuff.
+We know perfectly well what it would mean to require checks to be suppressed,
+and we would know it when we saw it if a compiler did not suppress the checks.
+The fact that you can't figure out how to say this formally in a language
+definition is irrelevant.
+
+That's why implementation advice is often much more powerful than requirements.
+In IA, you can say all sorts of things that
+
+a) make perfect sense
+b) are perfectly easy for everyone to understand
+c) can't be easily formalized
+
+so if we had IA saying
+
+Implementation advice
+
+The compiler should not generate any code corresponding to run time checks that
+are suppressed.
+
+We would understand that completely, and it might change implementations!
+
+> However, this supports your main point - "it is fine to insist on the
+> predicate check not being performed if it is suppressed" - because
+> omitting an assertion check doesn't introduce definitional problems.
+
+I really don't care much about definitional problems, I care about what the
+intention of the language design is. If we adopt a suppression/constraint model
+for predicates, I think it is just fine to have IA that says:
+
+     The compiler should not generate any code corresponding
+     to predicate checks that are suppressed.
+
+And if some language lawyer wants to start mumbling about erroneous ..
+anything-allowed .. including doing the predicate check.
+
+I won't pay much attention. Worrying about what erroneous means is a big waste
+of time from a practical point of view.
+
+...
+> In earlier discussions however, there was some support for the idea
+> that we don't want adding an assertion to make make a program less
+> reliable - the scenario some folks were concerned about is
+>       - user adds assertions for improved debugging, etc.
+>       - user disables them for the production version
+>       - some execution of the production version then becomes
+>         erroneous where it otherwise wouldn't have.
+>       - some catastrophic failure occurs which wouldn't have
+>         occurred if the assertion had never been written
+
+I think this scenario is 100% bogus. The rules of the language already allow
+implementations to do unacceptable things (do I need to restate my
+password-check/system disk deleted example), or to implement multiplication by
+recursive addition, but reasonable implementations don't do stupid things, just
+because the RM gives them formal permission to do so.
+
+> If folks want to avoid this problem, I could also live with
+> eliminating this special treatment for static predicates and instead
+> using the "suppression does not allow assumptions"
+> approach for all forms of assertions.
+
+I think that's a bad idea, you damage code quality for no good reason at all.
+
+> Robert Dewar wrote:
+>> I don't care, why not say it is a bounded error to have side effects,
+>> and the possible effects of a suppressed check is that it might or
+>> might not update the global or may set it to some unexpected value.
+>
+> I agree with the spirit of this remark. As long as we have
+> well-defined semantics for suppressing an assertion check, I'm less
+> concerned about the details. I just want them to be well-defined.
+
+Worrying about well-definedness when checks are suppressed is a total waste of
+time in my opinion. It won't change what implementations do, and it won't change
+what programmers do.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, March 6, 2012  1:02 PM
+
+>> No, the only reason we don't insist on the check being suppressed in
+>> the constraint case is that we don't have well-defined semantics for
+>> an execution which, for example, "successfully" writes to an
+>> out-of-bounds array element because the index check was suppressed.
+>
+> That's just not true historically.
+
+You're right.
+I probably should have said something like
+    "The main reason this is still the definition today, regardless
+     of how the language started out, is ..."
+
+I conclude this from more recent ARG discussions.
+
+> I really don't care much about definitional problems, I care about
+> what the intention of the language design is.
+> If we adopt a suppression/constraint model for predicates, I think it
+> is just fine to have IA that says:
+>
+>     The compiler should not generate any code corresponding
+>     to predicate checks that are suppressed.
+>
+
+Sounds good to me.
+
+>
+>> If folks want to avoid this problem, I could also live with
+>> eliminating this special treatment for static predicates and instead
+>> using the "suppression does not allow assumptions"
+>> approach for all forms of assertions.
+>
+> I think that's a bad idea, you damage code quality for no good reason
+> at all.
+
+I agree. I was just listing another option for those who object to the
+possibility of assertions introducing a new possibility for erroneous execution.
+
+****************************************************************
+
+From: Yannick Moy
+Sent: Tuesday, March 6, 2012  9:00 AM
+
+> I copy Yannick on this, because he is in charge of a major project
+> (Hi-Lite) that is concerned with mixing tests and proofs, and I think
+> his perspective may be useful. Yannick, can you review this thread?
+
+The issue for mixing tests and proofs is the ability to check dynamically
+(during testing) the assumptions that we are making statically (for proofs). So
+it does not matter how checks are enabled by the customer, because in this
+special testing mode, all RM checks will be enabled, and some additional checks
+will be performed. For example, we assume for proofs that all subcomponents of
+scalar type of an IN parameter of composite type are valid, and so we'll check
+during testing that this is the case when calling the subprogram (the new
+'Valid_Scalars attribute that you are going to implement!). This accounts for
+the fact the caller might be verified by testing and the callee by formal
+verification.
+
+So we must recompile all code to be able to insert the additional checks for
+testing, therefore the choice between alternatives (1) and (2) should not have
+any effect on our strategy above.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012  4:00 PM
+
+> > You might be right in terms of the language design. But these are
+> > very important details - get them wrong, and I (and many other
+> > programmers) will not be able to use Dynamic_Predicates for a
+> > substantial fraction of their intended purpose. That's very bad.
+>
+> Randy, this is is just over-the-top pessimistic!
+>
+> I'm quite sure we WILL get these rules wrong.  So what?
+> We'll work it out over the next couple of years.
+> Implementers will do what their customers need, and ARG will adjust
+> the rules accordingly.
+
+THAT'S exactly what I'm afraid of. 3rd party library developers are NOT the
+customers of any implementer. They *share* customers with implementers. At best,
+they are related to an implementer (so internal needs *might* get fixes made,
+but surely at a lower priority that those carrying the freight).
+
+The whole reason for having a standard is to put all of the customers and all of
+the implementers on as even a footing as possible. That includes those with less
+money!
+
+> > Moreover, even if we agree we want Suppression rules, I don't know
+> > how to (re)word the rules in 11.4.1 that assume that predicates are
+> > "assertions". We had so much trouble getting them right as it is
+> > (and that's assuming that they're right now, probably a dubious assumption),
+> > redoing them is a very scary task.
+>
+> Don't panic.  Steve is going to produce some wording.
+> If he gets it wrong, the sky will not fall.
+
+This wording is far more important than the "Ignore" rules. It essentially
+defines what can and cannot be used in assertions, and it's not something that
+we can change substantially after the fact.
+
+So while the "sky won't fall", Ada 2012 will. Perhaps AdaCore is comfortable in
+ignoring the standard when convinient, but in that case, why have it at all?
+
+> Compiler writers are going to understand one way or another, whether
+> predicates go by "erroneous" rules or "ignore" rules.
+> It really doesn't matter whether or not the wording says they are
+> "assertions".
+
+This has *nothing* to do with compiler writers. It has *everything* to do with
+what the creator of a subprogram can assume inside the subprogram based on the
+subtypes of the parameters. If checks off are erroneous (or if the checks can be
+"pinned" on, as with Preconditions), then the subprogram can assume the checks
+are made. But if the subprogram cannot assume the checks are made and the
+program is *not* erroneous if the checks fail, then the subprogram has to repeat
+the checks in the body (in which case, it is silly to include them in the
+specification in the first place).
+
+Most importantly, it will be completely impossible to change any existing
+package to use predicates rather than comments and body checks (especially
+language-defined packages), because in a checks off siituation, the checks will
+not be made as specified in the original interface. (I'll discuss this more in
+my response to J-P.) But a language feature that ought to be but cannot be used
+to describe Text_IO and containers and streams is seriously flawed and
+definitely not ready for prime-time.
+
+> > And the Standard is promised for delivery ASAP after March 1st
+> > (which has already passed). Most likely, that will be sometime next week.
+> > This wording all has to be done and letter balloted by then. That
+> > has me
+> > *very* scared.
+>
+> Take some advice from Alfred E. Newman.  ;-)
+
+Joyce has just told me that she needs the completed Standard on Monday.
+That's impossible even without this issue, and I'm unwilling to "finish" a
+standard that doesn't at least try to address this issue in some way. It's
+idiotic to standardize something with known bugs in important areas.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012  4:02 PM
+
+> > I don't think that works, because it would mean that both
+> (1) you have
+> > no control over whether clients make a check or not
+>
+> I really think it is a waste of time to worry about this. If people
+> turn off checks, they get what they get, I think that worrying too
+> much about the status of programs with checks that are turned off and
+> fail is pointless.
+
+It would be nice if that was true, but it surely is not true of assertions as it
+stands. Which means that they cannot be used to describe language-defined
+packages (or anything else existing), since there is no "exception" for someone
+having turned checks off.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012  4:14 PM
+
+> > You might be right in terms of the language design. But these are
+> > very important details - get them wrong, and I (and many other
+> > programmers) will not be able to use Dynamic_Predicates for a
+> > substantial fraction of their intended purpose. That's very bad.
+>
+> You keep saying this, but frankly I don't see "many other programmers"
+> here, and I don't sympathize with your concerns, since I think they
+> are misplaced. You are trying to push the language into a "Randy
+> Brukardt"
+> mold here when it just doesn't fit, and doesn't fit with normal Ada
+> usage.
+
+Both Erhard and Geert indicated that they have similar issues during the recent
+ARG meeting, and J-P has indicated such in e-mail. That's far more than no one
+else. I'm not going to try to guess whether they care about predicates at all
+(J-P seems to have said that he'd rather the Preconditions are used anyway), but
+I find it bizarre to define a feature that cannot safely be used for its
+intended purpose.
+
+...
+> We can fix this with a binding interpretation if necessary.
+> The Ada 2012 RM is full of errors, I am sure of that, no reason to
+> think we have succeeded in producing an error free document where we
+> never succeeded in doing this before.
+
+It has nothing to do with an "error-free" document. It's about producing a
+document that has the critical features "right". If dynamic predicates cannot be
+used on parameters because someone might turn off the checking, then we have a
+serious problem that needs to be addressed before going forward.
+
+This is *not* some corner case of little importance. It is all about whether you
+can even use predicates to describe the interface of a package (which was the
+only reason I wanted them in the first place - I much prefer
+constraints/predicates to preconditions).
+
+> So stop being scared, it is based on this faulty perception that there
+> is some merit in passing the Ada 2012 RM on to the next stage on a day
+> when we are not aware of any errors!
+
+I will not pass this standard forward if we aware of any errors in critical
+functionality. That would be idiotic. You can find someone else to do this if
+you want to do that.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 6, 2012  4:33 PM
+
+> It would be nice if that was true, but it surely is not true of
+> assertions as it stands. Which means that they cannot be used to
+> describe language-defined packages (or anything else existing), since
+> there is no "exception" for someone having turned checks off.
+
+So what? You seem to be fixated on this issue, but I just don't see it as
+critical. If someone turns checks off, they get what they get if the checks
+fail. If they are concerned about what happens when checks fail. they should be
+sure not to turn them off unless they are sure they won't fail.
+
+I just don't get it, and don't see what I am missing???
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 6, 2012  4:35 PM
+
+> THAT'S exactly what I'm afraid of. 3rd party library developers are
+> NOT the customers of any implementer. They *share* customers with
+> implementers.
+
+Randy, it's going to be several years, optimistically, before there are multiple
+Ada 2012 implementations.  That's plenty of time for ARG to nail down some rules
+about turning off assertions.
+
+> This wording is far more important than the "Ignore" rules. It
+> essentially defines what can and cannot be used in assertions, and
+> it's not something that we can change substantially after the fact.
+
+Heh?  All the rules about assertions are already nailed down, EXCEPT for the
+part about turning off the checks.
+
+> So while the "sky won't fall", Ada 2012 will. Perhaps AdaCore is
+> comfortable in ignoring the standard when convinient, but in that
+> case, why have it at all?
+
+Hyperbole.  AdaCore doesn't ignore the standard.
+
+> This has *nothing* to do with compiler writers. It has *everything* to
+> do with what the creator of a subprogram can assume inside the
+> subprogram based on the subtypes of the parameters. If checks off are
+> erroneous (or if the checks can be "pinned" on, as with
+> Preconditions), then the subprogram can assume the checks are made.
+> But if the subprogram cannot assume the checks are made and the
+> program is *not* erroneous if the checks fail, then the subprogram has
+> to repeat the checks in the body (in which case, it is silly to include them
+> in the specification in the first place).
+
+AdaCore is using assertions internally already, and some customers are also.  If
+you don't want to use them in your libraries, because of an (IMHO misguided)
+fear of users who turn off checks, that's fine. Or you could just tell your
+users not to turn off checks.  The checks-on semantics are fine today.
+
+> Most importantly, it will be completely impossible to change any
+> existing package to use predicates rather than comments and body
+> checks (especially language-defined packages), because in a checks off
+> siituation, the checks will not be made as specified in the original
+> interface. (I'll discuss this more in my response to J-P.) But a
+> language feature that ought to be but cannot be used to describe
+> Text_IO and containers and streams is seriously flawed and definitely not
+> ready for prime-time.
+
+To use preconditions or predicates in Text_IO, for ex, one needs a way to
+specify which exception gets raised (as you suggested at the Kemah meeting).  I
+strongly agree that's a good idea, and I strongly believe it's too late to add
+that feature to Ada 2012 now.
+
+> Joyce has just told me that she needs the completed Standard on Monday.
+
+So do the best you can in the next 2 weeks, and then give it to Joyce.
+
+> That's impossible even without this issue, and I'm unwilling to
+> "finish" a standard that doesn't at least try to address this issue in
+> some way. It's idiotic to standardize something with known bugs in important
+> areas.
+
+Assertions are important, but the exact semantics of turning them off is not.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012  4:40 PM
+
+> F.e., we do have to decide now if we raise Constraint_Error or
+> Assertion_Error for failures of subtype predicates.
+
+The exception raised is close to irrelevant. No matter what is choosen, it will
+be wrong for the vast majority of interfaces. We've already decided that we need
+more control, just that it is too late now to define that control.
+
+Just look at the language-defined packages, and look at things that ought to be
+defined as predicates or preconditions, and see which exceptions they raise:
+
+Containers.Vectors: Constraint_Error and Program_Error.
+Text_IO: Status_Error and Mode_Error.
+Generic_Elementary_Functions: Argument_Error.
+
+I know the same is true in Claw, and I'd expect it to be true in AWS, GTKAda,
+and all of the other existing libraries out there.
+
+...
+> And if people remove checks, all bets are off. If you  want something
+> guaranteed, write preconditions. I don't buy the argument "I'll make a
+> subtype because I need a precondition in various places", that's just
+> saving typing. If the subtype makes sense from the  problem domain,
+> fine, otherwise use preconditions.
+
+I strongly disagree with this. This is not about "saving typing", it's about
+readability by not cluttering the interface with mostly irrelevant junk. This
+depends on the subtype having a descriptive name, of course, but it seems
+similar to using named subtypes with constraints in the specification.
+
+Consider Stream_IO.
+
+I would probably want to define:
+
+    subtype Open_File_Type is File_Type
+       with Dynamic_Predicate => Is_Open (Open_File_Type),
+            Predicate_Fail_Raises => Status_Error;
+
+and then use it in the various routines:
+
+    function Name (File : in Open_File_Type) return String;
+    function Form (File : in Open_File_Type) return String;
+    procedure Set_Index (File : in Open_File_Type; To : in Positive_Count);
+
+Using preconditions would greatly clutter the specification (and obscure the
+real differences between the routines, and finding the routines themselves):
+
+    function Name (File : in File_Type) return String
+       with Pre => Is_Open (File),
+            Pre_Fail_Raises => Status_Error;
+
+    function Form (File : in File_Type) return String
+       with Pre => Is_Open (File),
+            Pre_Fail_Raises => Status_Error;
+
+    procedure Set_Index (File : in File_Type; To : in Positive_Count)
+       with Pre => Is_Open (File),
+            Pre_Fail_Raises => Status_Error;
+
+One could make an argument that these preconditions are clearer documentation
+than the predicates, but (1) clearly they are much larger; (2) the rule
+requiring this check isn't even given explicitly in A.12.1 [actually, I have to
+wonder if it is missing], repeating it everywhere when the authors of the
+Standard didn't feel the need to do so seems wrong; (3) why do we have a
+different rule about constraints?
+
+Specifically, I doubt that there is anyone that would say they you have to
+define Set_Index as:
+
+    procedure Set_Index (File : in File_Type; To : in Count'Base)
+       with Pre => Is_Open (File) and To > 0;
+
+because this is "clearer documentation" than using a subtype with a constraint!
+So why should "Open_File_Type" be different??
+
+But this example highlights the difference between Preconditions and Predicates.
+With the proposed semantics, it is OK to use a constraint to describe this
+interface (because the execution is erroneous with checking off), and OK to use
+a precondition (so long as Assertion_Policy (Check) is applied locally; then the
+predicate will always be checked), but it is not OK to use a predicate (because
+if the checks are off at the call site and the check would fail, the program is
+not erroneous but it also would not follow the language-defined specification --
+the exception raised probably would be the wrong one or none at all).
+
+I find this unacceptable, precisely because I think most programmers will think
+of constraints and predicates as interchangable (especially with Suppression
+semantics). If so, that had better be true, including when checks are suppressed
+somewhere. Otherwise, lots of people are going to misuse predicates and get
+burned.
+
+There may be some other way to deal with this (perhaps some sort of ImplPerm to
+void the checking semantics of predefined packages when called with checks off),
+but I think it would be best to either make constraints/predicates *exactly*
+equivalent (including erroneousness) or leave predicates completely as
+assertions. The middle ground is just a mess and leaves predicates not usable
+for their #1 intended purpose (at least in existing packages).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012  4:47 PM
+
+> > ...
+> > it is erroneous if the check would have returned False at the point
+> > of a suppressed check.
+>
+> With suppressed checks, Ada05 gives us an unambiguous definition of
+> when a program crosses the line into erroneousness.
+>
+> The line doesn't seem so clearly defined when we allow arbitrary
+> boolean expressions.
+>
+> Consider, for example, a predicate which has side effects.
+>
+> I know that such predicates are considered to be poorly behaved, but I
+> still want the language to be well-defined if someone does choose to
+> write such a thing.
+
+Why do we care? A compiler is allowed to reject such a program if it can
+identify it (within limits). So by definition, such code is not portable. Making
+it a bit more non-portable seems irrelevant.
+
+> What is the state of a program which depends on the value of a global
+> variable that a predicate function "would have"
+> updated?
+>
+> Is an implementation allowed (but of course not required) to perform a
+> suppressed assertion check?
+
+There can't be such a thing as a "suppressed assertion check". If we go with
+this model, these are simply checks, and they're definitely not assertions.
+Probably we would want them to be covered by some assertion rules, but that
+would require explicit inclusion.
+
+In any case, a program which depends on such a state is non-portable (the check
+may or may not be made), and thus I don't see why we care.
+
+I'd have to see a realistic example of why this matters in some case where it
+would not be possibly illegal by the 11.4.1 rules before I could even get 10%
+concerned.
+
+(This seems mainly to me to be an excuse to screw-up the rules more than a real
+concern.)
+
+That is, either make predicates 100% like constraints (with the possible
+addition of a few assertion rules on top), or make them 100% like assertions.
+Some sort of 90% rule seems like madness to me.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 6, 2012  4:49 PM
+
+> THAT'S exactly what I'm afraid of. 3rd party library developers are
+> NOT the customers of any implementer. They *share* customers with
+> implementers. At best, they are related to an implementer (so internal
+> needs *might* get fixes made, but surely at a lower priority that those
+> carrying the freight).
+
+Well we have lots of partnership agreements with 3rd party library developers,
+and work closely with them. After all you can't just blindly implement to your
+interpretation of the RM and expect it to work out of the box. Randy, if you are
+planning on developing libraries for Ada 2012, I would encourage you to open a
+partnership with AdaCore (at the moment the only Ada 2012 implementor in town
+:-)). This costs you nothing and we will be happy to work with you closely to
+make sure that you can effectively market your products to our customers, which
+is in everyone's interest.
+
+> The whole reason for having a standard is to put all of the customers
+> and all of the implementers on as even a footing as possible. That
+> includes those with less money!
+
+Well ultimately the issue is what implementors implement and not what the
+standard says. Of course Ada Core tries to follow the RM development as closely
+as possible, but with any formal release there will be differences. Right now,
+GNAT is based on the RM as it was several months ago, it will be another year
+before an updated version comes out. And of course we will try our hardest to
+remove remaining discrepancies, but that means we have quite a bit of time to
+iron out problems!
+
+> This wording is far more important than the "Ignore" rules. It
+> essentially defines what can and cannot be used in assertions, and
+> it's not something that we can change substantially after the fact.
+
+Of course we can change this substantially after the fact, we have always made
+substantial changes after the fact. Yes, you have to worry about implementors,
+but there is nothing
+
+> So while the "sky won't fall", Ada 2012 will. Perhaps AdaCore is
+> comfortable in ignoring the standard when convinient, but in that
+> case, why have it at all?
+
+Don't indulge in over-board rhetoric.
+Talking about Ada 2012 failing just means you have lost perspective. AdaCore
+will continue to follow the standard as closely as it can. if we find
+significant problems in the standard we will point them out and the standard
+will get fixed. if we find significant problems in GNAT, then we will fix those
+problems. As I say we have a year on the implementation side to get things in
+shape which should be enough time.
+
+(though I promise that even after a year, significant bugs will still be present
+both in the RM, and in GNAT!)
+
+> This has *nothing* to do with compiler writers. It has *everything* to
+> do with what the creator of a subprogram can assume inside the
+> subprogram based on the subtypes of the parameters. If checks off are
+> erroneous (or if the checks can be "pinned" on, as with
+> Preconditions), then the subprogram can assume the checks are made.
+> But if the subprogram cannot assume the checks are made and the
+> program is *not* erroneous if the checks fail, then the subprogram has
+> to repeat the checks in the body (in which case, it is silly to include them
+> in the specification in the first place).
+
+I disagree, it is perfectly reasonable for the spec of a 3rd party library to
+say that if checks are turned off, and the checks fail, then all bets are off.
+This is what any user of the library will assume anyway.
+
+> Most importantly, it will be completely impossible to change any
+> existing package to use predicates rather than comments and body
+> checks (especially language-defined packages), because in a checks off
+> siituation, the checks will not be made as specified in the original
+> interface. (I'll discuss this more in my response to J-P.) But a
+> language feature that ought to be but cannot be used to describe
+> Text_IO and containers and streams is seriously flawed and definitely not
+> ready for prime-time.
+
+I think this is just seriously flawed thinking, and I don't really know where it
+comes from. For example, if you turn off constraint checking and you pass
+rubbish to standard library routines, you get rubbish behavior. That's always
+been the case, what's the big deal???
+
+> Joyce has just told me that she needs the completed Standard on Monday.
+> That's impossible even without this issue, and I'm unwilling to
+> "finish" a standard that doesn't at least try to address this issue in
+> some way. It's idiotic to standardize something with known bugs in important areas.
+
+And that is the attitude that you need to review. The standard will have bugs in
+important areas. The fact that you know them does not make any difference from
+not knowing them. There is nothing special about a day on which you don't know
+about any of the serious bugs in important areas that remain!
+
+To think otherwise is a recipe for uselessly delaying release indefinitely,
+since there may never be such a day.
+
+We certainly never have released a version of GNAT Pro that did not contain
+known errors. That's because the release process takes months, and in those
+months we will find errors with fixes that are too late to incorporate.
+
+In this situation, we document the problems, and fix them, and customers who
+need a particular fix can get an intermediate unofficial relase that fixes known
+problems.
+
+I don't see the development of a language standard as being any different!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 6, 2012  4:53 PM
+
+> Both Erhard and Geert indicated that they have similar issues during
+> the recent ARG meeting, and J-P has indicated such in e-mail. That's
+> far more than no one else. I'm not going to try to guess whether they
+> care about predicates at all (J-P seems to have said that he'd rather
+> the Preconditions are used anyway), but I find it bizarre to define a
+> feature that cannot safely be used for its intended purpose.
+
+Let Erhard and Geert and JP speak for themselves. I know you are misrepresenting
+Geert's viewpoint, because I just spent a couple of hours talking about this
+issue with him today!
+
+> It has nothing to do with an "error-free" document. It's about
+> producing a document that has the critical features "right". If
+> dynamic predicates cannot be used on parameters because someone might
+> turn off the checking, then we have a serious problem that needs to be
+> addressed before going forward.
+
+You think it's a serious problem, it's not at ALL clear that this is a majority,
+let alone a consensus position!
+
+> This is *not* some corner case of little importance. It is all about
+> whether you can even use predicates to describe the interface of a
+> package (which was the only reason I wanted them in the first place -
+> I much prefer constraints/predicates to preconditions).
+
+Well it's not the only reason I wanted them, and I think you will find your
+viewpoint is not a consensus position.
+
+> I will not pass this standard forward if we aware of any errors in
+> critical functionality. That would be idiotic. You can find someone
+> else to do this if you want to do that.
+
+We may have to!
+Obviously the issue of whether the standard is passed on is not the decision of
+one person, it is a collective decision of the ARG. No one person can hold it
+hostage to their own viewpoint.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012  4:55 PM
+
+...
+> > This wording is far more important than the "Ignore" rules. It
+> > essentially defines what can and cannot be used in assertions, and
+> > it's not something that we can change substantially after the fact.
+>
+> Heh?  All the rules about assertions are already nailed down, EXCEPT
+> for the part about turning off the checks.
+
+I strongly believe that if we want predicates to act like constraints, that's
+fine (and indeed the way I originally envisioned them), but in that case they
+are *not* assertions (assertions raise Assertion_Error, are controlled by
+assertion policy, etc.). We would want some of the assertion rules to apply to
+them, but surely not all (probably not even a large number, maybe just the
+"error if significant side-effects" rules).
+
+That will require rewriting some or all of the assertion rules, at a very late
+date.
+
+I am strongly opposed to trying to make these half-assertions and
+half-constraints -- that way lies madness (mine, at least).
+
+>> Most importantly, it will be completely impossible to change any
+>> existing package to use predicates rather than comments and body
+>> checks (especially language-defined packages), because in a checks
+>> off siituation, the checks will not be made as specified in the
+>> original interface. (I'll discuss this more in my response to J-P.)
+>> But a language feature that ought to be but cannot be used to
+>> describe Text_IO and containers and streams is seriously flawed and
+>> definitely not
+ready for prime-time.
+
+>To use preconditions or predicates in Text_IO, for ex, one needs a way to
+>specify which exception gets raised (as you suggested at the Kemah meeting).
+>I strongly agree that's a good idea, and I strongly believe it's too late
+>to add that feature to Ada 2012 now.
+
+Right (I agree with all of the above), but so what? If the checking behavior is
+broken such that the predicates aren't checked as required by the standard in
+such an interface, you can't use them even if you have the right exceptions
+getting raised. That's what we have to get right now; the rest of it will have
+to wait (hopefully not very long).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 6, 2012  4:56 PM
+
+> ...
+> To use preconditions or predicates in Text_IO, for ex, one needs a way
+> to specify which exception gets raised (as you suggested at the Kemah
+> meeting).  I strongly agree that's a good idea, and I strongly believe
+> it's too late to add that feature to Ada 2012 now.
+
+Geert had an interesting suggestion of writing a precondition as:
+
+   procedure Read(File : File_Type; ...)
+     with Pre => Is_Open(File) or else Raise_Status_Error;"
+
+This seems like a neat way to get the right exception raised, at least for a
+precondition.
+
+For what that's worth.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 6, 2012   4:57 PM
+
+> Containers.Vectors: Constraint_Error and Program_Error.
+> Text_IO: Status_Error and Mode_Error.
+> Generic_Elementary_Functions: Argument_Error.
+
+Geert has been looking at the GEF issues, and has some very nice solutations
+that require no change in the language whatever we decide.
+
+> I know the same is true in Claw, and I'd expect it to be true in AWS,
+> GTKAda, and all of the other existing libraries out there.
+
+I would not speak for others!
+
+> I strongly disagree with this. This is not about "saving typing", it's
+> about readability by not cluttering the interface with mostly irrelevant junk.
+> This depends on the subtype having a descriptive name, of course, but
+> it seems similar to using named subtypes with constraints in the specification.
+
+Yes, similar indeed!
+
+> There may be some other way to deal with this (perhaps some sort of
+> ImplPerm to void the checking semantics of predefined packages when
+> called with checks off), but I think it would be best to either make
+> constraints/predicates *exactly* equivalent (including erroneousness)
+> or leave predicates completely as assertions. The middle ground is
+> just a mess and leaves predicates not usable for their #1 intended
+> purpose (at least in existing packages)
+
+I agree a middle ground is dubious. I would like constraints and predicates to
+be as similar as possible (I never like the term equivalent, even without exact
+in front of it). And indeed similar wrt erroneousness. I think that's the right
+way to go.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 6, 2012   5:00 PM
+
+> To use preconditions or predicates in Text_IO, for ex, one needs a way
+> to specify which exception gets raised (as you suggested at the Kemah
+> meeting).  I strongly agree that's a good idea, and I strongly believe
+> it's too late to add that feature to Ada 2012 now.
+
+Geert is busy adding preconditions and postconditions to our numeric library
+routine, looks like things are working out VERY nicely without needing any new
+features in this direction.
+
+I will let him speak for himself on the details!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012   5:02 PM
+
+> > It would be nice if that was true, but it surely is not true of
+> > assertions as it stands. Which means that they cannot be used to
+> > describe language-defined packages (or anything else existing), since
+> > there is no "exception" for someone having turned checks off.
+>
+> So what? You seem to be fixated on this issue, but I just don't see it
+> as critical. If someone turns checks off, they get what they get if
+> the checks fail. If they are concerned about what happens when checks
+> fail. they should be sure not to turn them off unless they are sure
+> they won't fail.
+>
+> I just don't get it, and don't see what I am missing???
+
+That's fine *if the language says that*. It *does* say that for constraints, but
+not for assertions. For assertions other than predicates, you can use a local
+assertion policy to "pin" them turned on, so you can be covered. But there is
+nothing that will allow predicates to be either forced to be checked or which
+makes execution "incorrect" if they would have failed.
+
+For instance, using predicates as I suggested in J-P's reply in Stream_IO.
+The standard says "Status_Error is raised if File is not  open." It does
+*not* say "Status_Error is raised if File is not open and predicate checks are
+not suppressed." So an implementation using a predicate would not be conformant
+to the standard. This seems bad, especially as a similar constraint would be OK.
+(If we want these to act like constraints, they ought to act 100% like
+constraints, not 75%. I think you actually agree, you just don't know it. :-)
+
+See my reply to J-P for more detail.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 6, 2012  5:02 PM
+
+> I am strongly opposed to trying to make these half-assertions and
+> half-constraints -- that way lies madness (mine, at least).
+
+I tend to agree with this, although it is far from driving me mad, Indeed I
+don't think it's that important what we decide.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012  5:08 PM
+
+> > To use preconditions or predicates in Text_IO, for ex, one needs a
+> > way to specify which exception gets raised (as you suggested at the
+> > Kemah meeting).  I strongly agree that's a good idea, and I strongly
+> > believe it's too late to add that feature to Ada 2012 now.
+>
+> Geert is busy adding preconditions and postconditions to our numeric
+> library routine, looks like things are working out VERY nicely without
+> needing any new features in this direction.
+
+I believe Geert was going to use the proposed mechanism for specifying the
+exception to be raised. I know he was *very* interested in it.
+
+In any case, preconditions work "right" in this sense; you can force them to be
+checked at all calls regardless of the caller's assertion policy. So you can
+match the existing semantics exactly.
+
+I just want to be able to use predicates in the same way.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, March 6, 2012  5:16 PM
+
+Randy Brukardt wrote:
+> If checks off are erroneous (or if the checks can be "pinned" on, as
+> with Preconditions), then the subprogram can assume the checks are
+> made. But if the subprogram cannot assume the checks are made and the
+> program is *not* erroneous if the checks fail, then the subprogram has
+> to repeat the checks in the body (in which case, it is silly to
+> include them in the specification in the first place).
+
+Tucker Taft wrote:
+> I think a rule that associates the assertion policy with the location
+> of the "final" explicit predicate expression that is applicable to the
+> subtype could work.
+
+Randy would like a way to have a predicate he can count on, at least for
+incoming parameters. Seems like a good idea to me.
+
+Let's look at a variation on Tuck's approach (or perhaps this is Tuck's approach
+exactly - I'm not sure).  If the assertion policy in effect at the point of a
+predicate specification is Ignore, then that new contribution to the subtype's
+predicate is ignored (with respect to runtime checking; not with respect to
+static semantics or membership tests). However, any "inherited" predicates are
+unaffected by the assertion policy in effect at the point of inheritance. For
+example
+
+    declare
+      pragma Assertion_Policy (Check);
+      subtype Even is Integer with Dynamic_Predicate => Even mod 2 = 0;
+
+      package Pkg is
+        pragma Assertion_Policy (Ignore);
+
+        subtype Multiple_Of_Six is Even
+          with Dynamic_Predicate => Multiple_Of_Six mod 3 = 0;
+      end Pkg;
+
+      X : Mos := 4; -- succeeds; mod 3 check was ignored
+      Y : Mos := 3; -- fails; mod 2 check was not ignored
+
+This means that subtype Even can be trusted if you declare a parameter of
+subtype Even.
+
+This approach also eliminates all the conformance issues that I was bringing up
+earlier; a given subtype has the same properties in all contexts.
+
+Randy continued:
+>> I know that such predicates are considered to be poorly
+>> > behaved, but I still want the language to be well-defined if
+>> > someone does choose to write such a thing.
+>
+> Why do we care? A compiler is allowed to reject such a program if it
+> can identify it (within limits). So by definition, such code is not portable.
+> Making it a bit more non-portable seems irrelevant.
+
+I'm starting to think you are right. I can live with erroneousness in this case
+(more specifically, I feel less nervous about this than I did before).
+
+Randy also said:
+> That is, either make predicates 100% like constraints (with the
+> possible addition of a few assertion rules on top), or ...
+
+Have you changed your position? I thought that in Houston you were saying that
+you didn't want assertions to provide a new path to erronousness (see the
+"catastrophic failure" scenario in a previous message from me today).
+
+I'm going to hit the send button before trying to digest the flurry of messages
+on this thread that have arrived while I was composing this one. Hopefully this
+won't be OBE at birth (well, actually, it would be great if there is a wonderful
+solution that everyone is happy with waiting in my mailbox).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012  5:331 PM
+
+...
+> Randy also said:
+> > That is, either make predicates 100% like constraints (with the
+> > possible addition of a few assertion rules on top), or ...
+>
+> Have you changed your position? I thought that in Houston you were
+> saying that you didn't want assertions to provide a new path to
+> erronousness (see the "catastrophic failure" scenario in a previous
+> message from me today).
+
+Not really. I'd prefer there wasn't a new path to erroneousness. But I was
+trying to explain what I could and could not live with. While I don't like the
+"erroneous" solution all that much, it has the advantage of being consistent
+with the current language (vis-a-vis constraints). As such, I think I'd be
+sawing off the limb I'm sitting on if I tried to oppose that! (I could make a
+case that the current definition of Suppress is harmful, but I doubt that anyone
+would care, because we're not changing that.) OTOH, I would oppose a "solution"
+that neither provides checking guarantees nor the "erroneous" escape hatch.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, March 6, 2012  5:49 PM
+
+> If the assertion policy
+> in effect at the point of a predicate specification is Ignore, then
+> that new contribution to the subtype's predicate is ignored (with
+> respect to runtime checking; not with respect to static semantics or
+> membership tests). However, any "inherited" predicates are unaffected
+> by the assertion policy in effect at the point of inheritance.
+
+If we don't want to require that implementations go through the bother of having
+to maintain, in effect, two different predicates for one subtype (one for
+checking, one for membership tests), we could also allow implementations to
+reject a predicate spec if it applies to a subtype that already has a predicate
+spec and the two specs differ with respect to applicable assertion policy.
+
+The Multiple_Of_Six subtype in my previous example could then be rejected (we
+could make the rejection either optional or mandatory).
+
+****************************************************************
+
+From: Randy Brukradt
+Sent: Tuesday, March 6, 2012  6:04 PM
+
+> If we don't want to require that implementations go through the bother
+> of having to maintain, in effect, two different predicates for one
+> subtype (one for checking, one for membership tests), we could also
+> allow implementations to reject a predicate spec if it applies to a
+> subtype that already has a predicate spec and the two specs differ
+> with respect to applicable assertion policy.
+>
+> The Multiple_Of_Six subtype in my previous example could then be
+> rejected (we could make the rejection either optional or mandatory).
+
+Wouldn't that break privacy? If the predicate was on the full type of a private
+type, you couldn't see it, and rejecting based on something you can't see is a
+no-no. Also, there might be contract problems (subtype of a formal type adds a
+predicate, actual subtype has a predicate).
+
+My original idea was essentally as you've outlined (sans legality rules).
+
+Tucker's idea was to have the *last* subtype that explicitly has a predicate
+control whether the checking is on or off (for the entire predicate). That
+somewhat avoids the "two predicate" problem, by making the "checking" one
+trivial (or identical to the membership one).
+
+That might have some problems with inheritance, but arguably that's in the noise
+compared with the alternatives. (And arguably, if you are overriding routines
+that had checking on with routines that have checking off, you know what you are
+doing, or at least shouldn't be surprised.)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 6, 2012  5:50 PM
+
+> > Heh?  All the rules about assertions are already nailed down, EXCEPT
+> > for the part about turning off the checks.
+>
+> I strongly believe that if we want predicates to act like constraints,
+> that's fine (and indeed the way I originally envisioned them), but in
+> that case they are *not* assertions (assertions raise Assertion_Error,
+> are controlled by assertion policy, etc.).
+
+That's fine with me, too.
+
+> That will require rewriting some or all of the assertion rules, at a
+> very late date.
+
+OK, but Steve has volunteered to write up some wording.  Yes, it's late, and we
+might get it (slightly) wrong -- no big deal.  Anyway, I suggest we quit all
+this handwringing, and wait for Steve's wording.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012  6:07 PM
+
+...
+> OK, but Steve has volunteered to write up some wording.  Yes, it's
+> late, and we might get it (slightly) wrong -- no big deal.
+
+I could live with "slightly", but I worry that it would be much worse.
+
+> Anyway, I suggest we quit all this handwringing, and wait for Steve's
+> wording.
+
+No "handwringing" here. Gnashing of teeth and wild pacing, perhaps. :-)
+
+In any case, if he'd get on with it, we could stop discussing this. But he
+wanted guidance, and that requires considering all of the possibilities,
+including FUD about some. :-)
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, March 6, 2012  6:17 PM
+
+>> The Multiple_Of_Six subtype in my previous example could then be
+>> rejected (we could make the rejection either optional or mandatory).
+>
+> Wouldn't that break privacy? If the predicate was on the full type of
+> a private type, you couldn't see it, and rejecting based on something
+> you can't see is a no-no. Also, there might be contract problems
+> (subtype of a formal type adds a predicate, actual subtype has a predicate).
+
+Yes, you're right. Scratch that dumb idea.
+
+> My original idea was essentally as you've outlined (sans legality rules).
+>
+> Tucker's idea was to have the *last* subtype that explicitly has a
+> predicate control whether the checking is on or off (for the entire
+> predicate). That somewhat avoids the "two predicate" problem, by
+> making the "checking" one trivial (or identical to the membership one).
+
+Right. And what's wrong with that approach? It seems like it still buys you what
+you want - a subtype whose predicate can be trusted. If you have a subtype
+Speckled_Foo declared with assertion policy Check in force, and if you declare
+your exported subprogram's parameter to be of subtype Speckled_Foo, then what's
+the problem?
+
+Somebody else can declare a subtype of Speckled_Foo with Checks_Ignored and
+supply a new predicate of, say, True, but that won't help them break your
+interface.
+
+What is the objection to Tuck's proposal?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 6, 2012  6:39 PM
+
+I don't have one. I was concerned that there was a possible hole via inheritance
+and overriding and dispatching, but I think I was wrong about that, as
+overriding requires subtype conformance (for dispatching primitives), and as
+such you can't change the name of the subtype involved. Thus you can't change
+the state of the checking, either.
+
+Thus I'm wholeheartedly in favor of working out the details of Tuck's latest
+proposal to see if any problems pop up. Otherwise, it seems to be the least
+change from the previous proposals and has the right semantics on the margin.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 6, 2012  6:43 PM
+
+...
+> Let's look at a variation on Tuck's approach (or perhaps this is
+> Tuck's approach exactly - I'm not sure). If the assertion policy in
+> effect at the point of a predicate specification is Ignore, then that
+> new contribution to the subtype's predicate is ignored (with respect
+> to runtime checking; not with respect to static semantics or
+> membership tests). However, any "inherited" predicates are unaffected
+> by the assertion policy in effect at the point of inheritance. For
+> example...
+
+I started with that, but didn't like having "partial" predicates.  I believe it
+should either be on or off.  Not halfway on.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, March 7, 2012  4:04 AM
+
+Hard to stay in sync with all these messages arriving while you sleep...
+Some specific responses:
+
+Le 06/03/2012 23:40, Randy Brukardt a ‚crit :
+> Using preconditions would greatly clutter the specification (and
+> obscure the real differences between the routines, and finding the routines
+> themselves):
+>
+>     function Name (File : in File_Type) return String
+>        with Pre => Is_Open (File),
+>             Pre_Fail_Raises => Status_Error;
+>
+>     function Form (File : in File_Type) return String
+>        with Pre => Is_Open (File),
+>             Pre_Fail_Raises => Status_Error;
+>
+>     procedure Set_Index (File : in File_Type; To : in Positive_Count)
+>        with Pre => Is_Open (File),
+>             Pre_Fail_Raises => Status_Error;
+
+As a matter of personal taste, I'm not worried by this, but YMMV of course. I'm
+certainly willing to accept it if it allows for a simple rule like:
+  "predicates are controlled by the caller, as a callee either you
+   recheck or you accept erroneousness.
+   preconditions are controled by the callee, the caller can't bypass
+   them"
+
+> For instance, using predicates as I suggested in J-P's reply in Stream_IO.
+> The standard says "Status_Error is raised if File is not  open." It
+> does
+> *not* say "Status_Error is raised if File is not open and predicate
+> checks are not suppressed." So an implementation using a predicate
+> would not be conformant to the standard.
+
+But Set_Col expects a value of subtype Positive_Count. With check suppressed,
+you could pass it a value of 0. Would you say that an implementation that does
+not move the cursor left of the left edge of the screen is not conformant ;-)?
+
+> In any case, preconditions work "right" in this sense; you can force
+> them to be checked at all calls regardless of the caller's assertion
+> policy. So you can match the existing semantics exactly.
+>
+> I just want to be able to use predicates in the same way.
+
+That's where we don't agree: I think there is more value in having predicates
+AND preconditions if they DON'T behave the same way. The one you chose depends
+on the kind of semantics you want, not on the amount of typing involved
+(slightly tong in cheek).
+
+>  I'd prefer there wasn't a new path to erroneousness.
+
+This is the original reason for all this discussion. I don't think it is a /new/
+path for erroneousness. We extend the notion of constraint, therefore we extend
+the corresponding /existing/ erroneousness to cover those new features. I'd say
+that, presented this way, it would be no surprise to the user.
+
+Anyway, a fundamental point of suppressing checks is that it should be done only
+when you can prove (more or less) formally that the suppressed condition cannot
+happen. I would go as far as saying that a compiler that sees checks suppressed
+is allowed to assume that the condition has been formally proven by means
+outside its own realm. The user who fails to ensure this will get what he
+deserves (erroneousness, nasal daemons, ...)
+
+-------------
+At this point, I  propose a motion:
+
+Preconditions are not assertions, they are "extended constraints"
+=> Failing a precondition raises Constraint_Error => Checking preconditions is
+   governed by pragma Suppress at the point where a check is required.
+=> It is erroneous to force a false precondition by mean of suppressing
+   checks.
+
+Any seconder? Straw poll?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 7, 2012  7:45 AM
+
+> As a matter of personal taste, I'm not worried by this, but YMMV of
+> course. I'm certainly willing to accept it if it allows for a simple
+> rule like:
+>    "predicates are controlled by the caller, as a callee either you
+>     recheck or you accept erroneousness.
+
+That seems just right to me, I think most library writers will be happy to
+accept erroneousness (if callers suppress checks, and then pass garbage, it
+seems fine to consider this erroneous to me).
+
+An implementation can certainly provide some pragma, policy or whatever to
+implement the rechecking automatically, and I think it's worth allowing some
+time to figure out how to do that in the most useful way, rather than rushing to
+design this now.
+
+>     preconditions are controled by the callee, the caller can't bypass
+>     them"
+
+Again, an implementation may want to have a mode, pragma, or policy that does
+allow them to be ignored under control of the caller. After all, for example in
+certified systems, you often really don't want runtime checks of ANY kind at
+all, since they can generate a lot of extra work in coverage testing.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, March 7, 2012  8:26 AM
+
+What about when the library is delivered as a DLL - increasingly the case -
+possibly compiled with a different version (or even vendor or revision of Ada)
+of the compiler, when the only checking will be whatever minimum is enforced by
+the linker, which often doesn't amount to much more than matching up symbol
+names.  I think it would be very difficult for predicates in the library to be
+enforced on the caller.  The library would either have to be paranoid and
+re-check, or any assumptions about its use spelt out in black  white in its user
+guide.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, March 7, 2012  8:34 AM
+
+At least in Ada, you would still be providing the Ada package spec in source
+code, and you could still have your Assertion_Policy pragma there.  Of course if
+they edit the source code for the provided Ada package spec, then all bets are
+off.  But I think the general idea that "normal" users won't cause trouble doing
+their own "normal" thing is a reasonable goal.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, March 7, 2012  8:37 AM
+
+Some users I've seen would edit the specs just so in the hope of making their
+code more efficient or avoiding irritating errors...  :-(
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 7, 2012  8:59 AM
+
+Sure, and that is why it may be appropriate to have switches, pragmas, or
+policies that cause contract stuff to be ignored. If that makes more sleepless
+nights for Randy, sorry, but we need things that accomodate all users needs :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 7, 2012  12:07 PM
+
+No, that's fine by me. So long as it is clearly a "non-standard mode" in the
+sense of the Standard, it's not a problem. If some customer wants us to support
+Claw in such a mode (one it was not designed or tested for), they can pay extra
+$$$ for the service. It's the "normal" case that I worry about.
+
+And I fully realize that some customers have requirements that are beyond the
+norm. For instance, if you need 100% coverage, you can't use the sort of
+"belt-and-suspenders" code that I typically write, simply because some of the
+"suspenders" checks are necessarily redundant and thus dead (and untestable)
+paths no matter what input you give. You (somewhat perversely) have to make your
+code less robust to meet such a requirement. But if you have this requirement,
+then you need a simpler version of some things than you would normally use, and
+it's fine to support such customers.
+
+I'm not particularly worried about Claw being used in a verification environment
+(anyone using Windows to underlie flight-critical software has completely lost
+their mind), so I don't think this will really come up in practice. But I could
+imagine it happening in other contexts (perhaps using the socket subset of Claw,
+extended Ada containers, etc.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 7, 2012  12:10 PM
+
+> At least in Ada, you would still be providing the Ada package spec in
+> source code, and you could still have your Assertion_Policy pragma
+> there.  Of course if they edit the source code for the provided Ada
+> package spec, then all bets are off.  But I think the general idea
+> that "normal" users won't cause trouble doing their own "normal" thing
+> is a reasonable goal.
+
+Moreover, it is perfectly reasonable for the Ada compiler to make the checks in
+the body in this case. It already has to be able to do that (at least for some
+subset of assertions) in order to support dispatching, and it probably has to do
+that to support Export, and this seems to be the same sort of thing.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 7, 2012  12:28 PM
+
+...
+> > For instance, using predicates as I suggested in J-P's reply in Stream_IO.
+> > The standard says "Status_Error is raised if File is not  open." It does
+> > *not* say "Status_Error is raised if File is not open and predicate
+> > checks are not suppressed." So an implementation using a predicate
+> > would not be conformant to the standard.
+> But Set_Col expects a value of subtype Positive_Count. With check
+> suppressed, you could pass it a value of 0. Would you say that an
+> implementation that does not move the cursor left of the left edge of
+> the screen is not conformant ;-)?
+
+That OK because execution is erroneous in that case. So anything is
+"conformant". The proposal I was reacting to was that predicates would be
+different and not erroneous.
+
+> >  I'd prefer there wasn't a new path to erroneousness.
+
+> This is the original reason for all this discussion. I don't think it
+> is a /new/ path for erroneousness. We extend the notion of constraint,
+> therefore we extend the corresponding /existing/ erroneousness to
+> cover those new features. I'd say that, presented this way, it would
+> be no surprise to the user.
+
+Well, it's certainly a large expansion of erroneousness, especially as it now
+involved arbitrary expressions (and possibly side-effects) rather than just
+compares against precomputed values.
+
+> Anyway, a fundamental point of suppressing checks is that it should be
+> done only when you can prove (more or less) formally that the
+> suppressed condition cannot happen. I would go as far as saying that a
+> compiler that sees checks suppressed is allowed to assume that the
+> condition has been formally proven by means outside its own realm. The
+> user who fails to ensure this will get what he deserves
+> (erroneousness, nasal daemons, ...)
+
+I'm actually dubious that this is the right model for some existing Ada checks.
+In particular, range checks and null exclusion checks both have well-defined
+semantics as to what happens if the check is not made [you get an invalid
+value]. (This is not true for index checks, rendezvous checks, etc.) Like
+predicates, there is no good reason for these to cause erroneous execution when
+not made.
+
+Well, except that the model for suppress involves locations rather than
+declarations, so you can't tell inside a subprogram whether or not the checks
+were made. This IMHO is a completely bogus reason for introducing erroneousness
+(13.9.1(12/3) is another case where Ada introduces erroneousness to make life
+easier for the implementer without any semantic need). Especially as a different
+model for suppression would have eliminated the problem entirely.
+
+We're obviously not going to change any of this now, but I surely understand
+people who do not want to expand such "unnecessary" erroneousness.
+
+> -------------
+> At this point, I  propose a motion:
+>
+> Preconditions are not assertions, they are "extended constraints"
+> => Failing a precondition raises Constraint_Error => Checking
+>    preconditions is governed by pragma Suppress at the point
+>    where a check is required.
+> => It is erroneous to force a false precondition by mean of
+>    suppressing checks.
+
+I could live with this, but I'd prefer the model that Steve is working on (based
+on the last subtype declaration with a predicate). It would not introduce
+"unnecessary" erroneousness, and it's much closer to the model currently
+described in the Standard.
+
+As to the exception raised, that's a separate (and unrelated IMHO) question.
+And I don't think it matters, we have to be able to specify the exception raised
+as described in the not yet written AI12 split from AI05-0290-1. Geert indicated
+that he would implement it himself in GNAT because he needed it that much, so
+it's likely to be an available feature quite soon. (I surely will include that
+feature from the start when I implement predicates in Janus/Ada, it's very
+valuable.)
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Wednesday, March 7, 2012  12:46 PM
+
+I have always believed that Randy's specific examples are better expressed as
+PRE-conditions rather than wrapped into subtype predicates. I appreciate Randy's
+point, though, that in general there should not be a distinction between
+parameter type "Positive" and a PRE that forces the parameter to be positive.
+
+Still, if we cannot make it work any other way (in an easy to understand model),
+I opt for the alternative (2) including the erroneousness.
+
+P.S. And I do not give a hoot for users that have side-effects in their subtype
+predicates (or assertions). They will just have to live with the fact that the
+side-effects come and go as they like.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 7, 2012  12:49 PM
+
+> That OK because execution is erroneous in that case. So anything is
+> "conformant". The proposal I was reacting to was that predicates would
+> be different and not erroneous.
+
+I agree that this would be an undesirable situation. I am in favor of
+erroneousity :-)
+
+> Well, it's certainly a large expansion of erroneousness, especially as
+> it now involved arbitrary expressions (and possibly side-effects)
+> rather than just compares against precomputed values.
+
+I don't see it as a large expansion
+
+> I'm actually dubious that this is the right model for some existing
+> Ada checks. In particular, range checks and null exclusion checks both
+> have well-defined semantics as to what happens if the check is not
+> made [you get an invalid value]. (This is not true for index checks,
+> rendezvous checks,
+> etc.) Like predicates, there is no good reason for these to cause
+> erroneous execution when not made.
+
+I am confused, I thought the general rule was that any run-time check that is
+suppressed and fails results in erroneousness.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 7, 2012  1:08 PM
+
+...
+> > I'm actually dubious that this is the right model for some existing
+> > Ada checks. In particular, range checks and null exclusion checks
+> > both have well-defined semantics as to what happens if the check is
+> > not made [you get an invalid value]. (This is not true for index
+> > checks, rendezvous checks, etc.) Like predicates, there is no good
+> > reason for these to cause erroneous execution when not made.
+>
+> I am confused, I thought the general rule was that any run-time check
+> that is suppressed and fails results in erroneousness.
+
+That's the rule for checks that are *suppressed*. But Ada also goes to great
+lengths to say that even checks that are formally required don't actually have
+to be made, and describes that happens if they are not made (you get invalid
+values). Since we have that model, there is no semantic need to go all the way
+to erroneousness when such a check (like a range check) is not made because of
+suppression - there is no semantic difference between suppression and check
+optimization. The result of a suppressed range check is just potentially
+invalid, and that by itself does not need to cause any erroneous execution.
+
+For most other language-defined checks, there is no semantic model of what
+happens if a check is not made (indexing out of range, for instance), and thus
+erroneous execution is the only choice. Indeed, there is a requirement that an
+invalid value be detected in such situations (you can defer range checks, but
+you have to make index checks); so suppression is clearly a different beast
+here.
+
+In any case, I'm not proposing a change here; it's decades too late to make such
+a fundamental model change for Suppression.
+
+What I was saying is that predicates are much like range checks; there is no
+semantic need for execution to be erroneous after they are not checked. There
+are other reasons that that might need to be the case, but they are pragmatic
+and not semantic. As such, the best situation is to arrange the rules so the
+pragmatic problems don't arise either. Only if that isn't possible should we go
+to erroneous execution. (Steve is working on such a solution, I believe.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 7, 2012  1:16 PM
+
+> That's the rule for checks that are *suppressed*. But Ada also goes to
+> great lengths to say that even checks that are formally required don't
+> actually have to be made, and describes that happens if they are not
+> made (you get invalid values). Since we have that model, there is no
+> semantic need to go all the way to erroneousness when such a check
+> (like a range check) is not made because of suppression - there is no
+> semantic difference between suppression and check optimization. The
+> result of a suppressed range check is just potentially invalid, and
+> that by itself does not need to cause any erroneous execution.
+
+Sure I understand all this. No problem, I was thinking of the Suppress case
+
+I prefer to just go with the erroneousness for suppressed predicates, frankly I
+don't think programmers understand the intermediate case, to them there is only
+right code and wrong code, not really different degrees of wrongness :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 7, 2012  12:52 PM
+
+> I have always believed that Randy's specific examples are better
+> expressed as PRE-conditions rather than wrapped into subtype predicates.
+> I appreciate Randy's point, though, that in general there should not
+> be a distinction between parameter type "Positive" and a PRE that
+> forces the parameter to be positive.
+
+But there already is such a distinction, if you pass a non-positive value to a
+positive parameter and checks are suppressed, you are in erroneous territory
+anyway.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 7, 2012  1:00 PM
+
+> And I fully realize that some customers have requirements that are
+> beyond the norm. For instance, if you need 100% coverage, you can't
+> use the sort of "belt-and-suspenders" code that I typically write,
+> simply because some of the "suspenders" checks are necessarily
+> redundant and thus dead (and
+> untestable) paths no matter what input you give. You (somewhat
+> perversely) have to make your code less robust to meet such a
+> requirement. But if you have this requirement, then you need a simpler
+> version of some things than you would normally use, and it's fine to support such customers.
+
+It is not the case that adding run-time checks and exceptions etc necessarily
+makes code more robust. Surely Ariane-5 taught us that much!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 7, 2012  1:23 PM
+
+That's certainly true, but I was also thinking of handling cases that are not
+needed by callers. For instance, the query functions in the Janus/Ada compiler
+try to handle every kind of type, but it is quite possible that some of them are
+never called for certain kinds of types. That code can't be covered by basic
+coverage analysis (it could be with a special test harness, but that's a lot of
+work for dead code). That's always a problem when covering reusable code in a
+system.
+
+And I probably used the wrong word when I said "robust". In my projects, an
+early detection of errors and prevention of wrong answers is the most important
+criteria. I'd rather the programs didn't even try in that case, just report/log
+the error and tell the user to call tech support (preferably without damaging
+the ability to perform other operations). So that's what I think of as "robust".
+[Aside: That's even true of the web server; returning *something* to a
+bad/broken query is precisely how security holes are introduced. Doing nothing
+is safer, and much more recoverable. Similarly, I don't want the compiler trying
+to recover internal errors; that's just asking for the generation of bad code.]
+But it's obvious that there are many systems where completing the operation is
+paramount -- asking the pilot to call tech support while landing the plane is
+silly.
+
+Moral: one project's "robust" is another project's "fragile". One size does not
+fit all.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 7, 2012  1:25 PM
+
+> Moral: one project's "robust" is another project's "fragile". One size
+> does not fit all.
+
+yes, absolutely!
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, March 7, 2012  1:31 PM
+
+Steve is going to take a shot at writing up a new version.  It might be worth
+waiting to see if what he produces is reasonable as far as a version that can go
+in the 2012 standard that we won't regret later.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, March 7, 2012  1:43 PM
+
+In the interests of avoiding big changes at this late date, I am taking Tuck's
+previous version as a starting point and trying to change it as little as
+possible. The main change is that the assertion policy for a subtype no longer
+varies with where the subtype is used.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Wednesday, March 7, 2012  5:33 PM
+
+> Geert had an interesting suggestion of writing a precondition as:
+>
+>   procedure Read(File : File_Type; ...)
+>     with Pre => Is_Open(File) or else Raise_Status_Error;"
+
+If the decision goes the way it seems to go, please make sure to put this in the
+discussion in lieu of Randy's subtype predicate example with the same
+functionality that is currently there. In Houston, I blindly copied it; I should
+already have turned it into a PRE example.
+
+I'd go as far as to ratify this change even at such a late date!
+It is such an obvious and major improvement without hidden traps.
+
+[Editor's note: Further discussion on this topic is included in AI12-0022-1,
+which formally proposed this feature. - Editor.]
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Wednesday, March 7, 2012  5:35 PM
+
+> Changing invariants to raise Constraint_Error is OK with me to do now.
+
+Presumably you meant subtype predicates, not type invariants.
+(This whole discussion is not about type invariants, which are fine the way they
+are.)
+
+I agree, too, that under choice (2), subtype predicate checks need to raise C_E.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 7, 2012  5:39 PM
+
+Yes, I agree with this--it's an incompatibility, but in practice not a big one
+(it is rare for people to write handlers for either exception in a case like
+this).
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, March 8, 2012  12:24 PM
+
+> In the interests of avoiding big changes at this late date, I am
+> taking Tuck's previous version as a starting point and trying to
+> change it as little as possible. The main change is that the assertion
+> policy for a subtype no longer varies with where the subtype is used.
+
+See attached. [This is version /06 of the AI. - Editor.]
+
+Highlights include:
+    New rules for deciding whether predicate checking is enabled for
+    a subtype. This is generally determined by the assertion policy
+    in effect at the point of the "nearest" predicate specification.
+
+    Deal with variant_parts the same way we already handle case stmts
+    and case exprs - C_E if no choice covers selector value.
+
+    Fix tiny hole in definition of "statically compatible".
+
+    Add AARM comments explaining how pragmas Assertion_Policy
+    and Suppress interact with instantiations.
+
+Thanks to Tuck and Bob for preliminary review and suggested improvements.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, March 8, 2012  2:51 PM
+
+> Highlights include:
+>      New rules for deciding whether predicate checking is enabled for
+>      a subtype. This is generally determined by the assertion policy
+>      in effect at the point of the "nearest" predicate specification.
+>
+>      Deal with variant_parts the same way we already handle case stmts
+>      and case exprs - C_E if no choice covers selector value.
+>
+>      Fix tiny hole in definition of "statically compatible".
+>
+>      Add AARM comments explaining how pragmas Assertion_Policy
+>      and Suppress interact with instantiations.
+
+I think we should have failed predicates raise CE
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, March 8, 2012  3:02 PM
+
+> I think we should have failed predicates raise CE
+
+I was trying to minimize last-minute Ada 2012 changes so I didn't even consider
+this.
+
+However, the wording for this change would be trivial if we decide to do it;
+just change the final sentence of 3.2.4(23)
+
+    Assertions.Assertion_Error is raised if any of these checks fail.
+to
+    Constraint_Error is raised if any of these checks fail.
+
+We just need to agree on what we want to do.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, March 8, 2012  3:32 PM
+
+I don't think I agree with Robert.
+
+I do agree that at some point we should provide a way to control exactly which
+exception it raises, but we should leave the default for now as Assertion_Error.
+It is controlled by Assertion_Policy and it is called an "assertion expression."
+
+If we had gone the other route, and made it controlled by Suppress and not
+called an "assertion expression" then I would agree it should raise
+Constraint_Error.
+
+Raising Constraint_Error is not really what you want in the long run either.
+You would like a user-specified exception.  But at this point, consistency
+counts, and based on the proposed AI, that means the default should be
+Assertion_Error, in my view.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, March 8, 2012  3:39 PM
+
+> If we had gone the other route, and made it controlled by Suppress and
+> not called an "assertion expression" then I would agree it should
+> raise Constraint_Error.
+
+I think we should have gone the other route and have it controlled by suppress.
+
+Actually, come to think of it, in GNAT, since we have something called
+Predicate, we could devise our own rules for that. Interesting, means that you
+would have both possibilities.
+
+Bob, what do you think
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, March 8, 2012  5:08 PM
+
+> Bob, what do you think
+
+I think we should all stop distracting Randy from the job at hand, which is to
+crank out an RM with minimal changes from what we've already got.  Steve has
+done a good job of nailing down the last remaining item.
+
+I suggest we defer all talk about 2020 features and impl-def features until WG9
+approves the RM.
+
+P.S. I'm going on vacation right about now...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, March 8, 2012  6:12 PM
+
+I take it you're in favor of starting a letter ballot on Steve's version of the
+AI? I was thinking of doing that tonight, but was not sure if it was premature.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, March 8, 2012  6:25 PM
+
+> I take it you're in favor of starting a letter ballot on Steve's
+> version of the AI? I was thinking of doing that tonight, but was not
+> sure if it was premature.
+
+OK, if you think that's the best way forward.
+
+I vote "yes" on Steve's proposal.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, March 8, 2012  7:40 PM
+
+I also vote yes
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, March 8, 2012  8:19 PM
+
+> ... I take it you're in favor of starting a letter ballot on Steve's
+> version of the AI? I was thinking of doing that tonight, but was not
+> sure if it was premature.
+
+I vote "yes" as well.
+
+****************************************************************
+
+From: Geert Bosch
+Sent: Thursday, March 8, 2012  9:46 PM
+
+After finally having read this in detail, and compared with the existing
+languages in each section, I'd like to vote in favor of this version of the AI.
+
+I spotted two minor typos in the proposal and discussion sections, and suggest a
+one more sentence to the discussion, but that is at the editor's discretion.
+
+...
+> Hence, there needs to be fine control over the checks of various kinds
+> of assertions. Control for any but the Assert Pragma cannot be
+> sensibly based on a policy in effect at the point of the check. For
+> example, this would cause invariant checks to be performed only
+> occasionally.  The proposal is generally that the policy in effect at
+> the time of the aspect specification controls all its checks.
+> A key distinction between supressing a check and ignoring an assertion
+                           sup{p}ressing
+> (by specifying a policy of "Ignore") is that in the latter case, the
+> assertion expressions that are not evaluated because of the policy are
+> *not* assumed to be true.
+...
+>!discussion
+...
+> A clear separation was made between language checks that, if failing
+> but suppressed, render the program erroneous, and assertions, for
+> which suppression does not cause language issues that lead to
+> erroneousness. This is one of the reasons why assertion control was
+> not subsumed under the pragmas Suppress and Unsuppress with
+> appropriate check names. For example, in verified code, the policy
+> Ignore for Assertions make sense without impacting the program semantics.
+> (Supressing a range check on the other hand can lead to abnormal
+> values.)
+  Sup{p}ressing
+
+...
+> If we didn't have the "On_Failure" aspect here, using the predicate as
+> a precondition in lieu of a condition explicitly checked by the code
+> would change the exception raised on this failure to be
+> Assertion_Error. This would obviously not be acceptable for existing
+> packages and too limiting for future packages. For upward
+> compatibility, similar considerations apply to preconditions, so the
+> "On_Failure" aspect is needed for them as well. We could also imagine
+> that after one On_Failure aspect has been specified, additional
+> preconditions could be defined for the same subprogram with distinct
+> On_Failure aspects specifying distinct expressions to be raised.
+
+We might want to add the following (Geert's trick):
+{With the language as defined by the 2012 standard, the same result can be
+achieved by assertion conditions calling functions that raise the required
+exceptions on failure.}
+
+> -----
+>
+> For pragma Inline (and for Assertion_Policy), we decided to eliminate
+> the rule that said that the presence of a pragma Suppress or
+> Unsuppress at the point of a call would affect the code inside the
+> called body, if pragma Inline applies to the body. Given that inlining
+> is merely advice, and is not supposed to have any significant semantic
+> effect, having it affect the presence or absence of checks in the
+> body, whether or not it is actually inlined, seemed unwise.
+> Furthermore, in many Ada compilers, the decision to inline may be made
+> very late, so if the rule is instead interpreted as only having an
+> effect if the body is in fact inlined, it is still a problem, because
+> the decision to inline may be made after the decision is made whether to
+> insert or omit checks.
+
+(I'm so happy with the above language! Inlining should never have effect on
+semantics.)
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, March 9, 2012  12:36 AM
+
+> If a pragma Assertion_Policy applies to a generic_instantiation, then
+> the pragma Assertion_Policy applies to the entire instance.
+>
+> AARM note: This means that an Assertion_Policy pragma that occurs in a
+> scope enclosing the declaration of a generic unit but not also
+> enclosing the declaration of a given instance of that generic unit
+> will not apply to assertion expressions occuring within the given instance.
+
+Is this even possible with shared generics? I know they are now out of fashion,
+but this seems to require full duplication.
+
+-------------
+I have a feeling that since Steve was asked to write this one, there was more
+support for predicates-like-constraints (C_E, suppress, erroneous).
+
+Are we sure we want predicates-as-assertions? This is not something we can
+change later.
+
+I vote yes for the rest of the AI.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, March 9, 2012  12:55 AM
+
+> I have a feeling that since Steve was asked to write this one, there
+> was more support for predicates-like-constraints (C_E, suppress, erroneous).
+
+I don't quite understand what you are saying.  Steve wrote it up as
+predicates-as-assertions.  Are you saying you wished he had written it as
+"predicates-as-constraints," or are you saying you think *other* people might
+have wished for that? I recommend you just vote for yourself at this point.
+
+> Are we sure we want predicates-as-assertions? This is not something we
+> can change later.
+
+I think an implementor could certainly add a "Suppress(Predicate_Check)" with
+the obvious erroneousness-oriented semantics, even if we define the
+Assertion_Policy model as the standard one for predicates.
+
+> I vote yes for the rest of the AI.
+
+Not sure what you mean by this.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 9, 2012  1:30 AM
+
+> > If a pragma Assertion_Policy applies to a generic_instantiation, then
+> > the pragma Assertion_Policy applies to the entire instance.
+> >
+> > AARM note: This means that an Assertion_Policy pragma that occurs in a
+> > scope enclosing the declaration of a generic unit but not also
+> > enclosing the declaration of a given instance of that generic unit
+> > will not apply to assertion expressions occuring within the given instance.
+>
+> Is this even possible with shared generics? I know they are now out of
+> fashion, but this seems to require full duplication.
+
+Thanks for noticing this one, I missed it. The answer is NO; there is no
+possible way to do any significant sharing with this model. I don't care that
+much, in that I'll simply ignore this "rule" in Janus/Ada; it's impossible and
+makes no sense at all, so why care about it?
+
+I suppose one could pass in a bunch of Assertion_Policy flags to an instance and
+turn them off that way, but that's a nasty distributed overhead for something
+rarely used (most of the time, these will be all on or all off, or will have
+policies inside the generic that will override the one applying to the instance
+in any case).
+
+Note that the similar rule works for Suppress, simply because that is a
+permission that can be ignored. I'd still prefer the model for assertions (*all*
+assertions) is that as well, but as I've never gotten any traction with that,
+I'll shut up about that.
+
+I actually don't see any model of Assertion_Policy that could work for both
+shared generics and duplicated generics, short of making it
+implementation-defined, which is unpleasant at best. Saying that the policy that
+applies to the generic unit applies to the instance would work fine for shared
+generics and surely could be implemented for duplicated generics, but it seems
+like a pain in the latter case and it's not clear that it would make sense to
+users. (One could imagine to split the spec and body in this way, but that's
+just too confusing.
+
+So I guess I'm saying I don't care enough to try to change it; but if we did, it
+should be the exact opposite (the policy governing the generic rules; the one
+governing the instance doesn't matter inside it). (I may regret this stance
+someday, but whatever.)
+
+> -------------
+> I have a feeling that since Steve was asked to write this one, there
+> was more support for predicates-like-constraints (C_E, suppress,
+> erroneous).
+
+I think at least some of the supporters of that position had not considered all
+of the implications, and have changed their positions yet again.
+
+> Are we sure we want predicates-as-assertions? This is not something we
+> can change later.
+
+They (at least dynamic predicates) have to be at least partially assertions
+-- if not, then side-effects are allowed and have a defined meaning, protected
+actions could get hosed by blocking, and so on. It's not possible for dynamic
+predicates to be completely constraints.
+
+It would seem to be too confusing to treat static predicates differently from
+dynamic predicates in this area.
+
+Its clear that the exception raised is close to irrelevant; if you care, you'll
+specify it by whatever gizmo we end up designing (or by using Geert's trick).
+
+I, at least, am quite opposed to "unnecessary" erroneousness (that is,
+erroneouseness for a construct which has well defined semantics); there is far
+too much of it in the standard already. [As I previously noted, I don't think
+the suppress of range checks should be allowed to cause erroneous execution.]
+
+Finally (and leastly), no one has ever volunteered to do the rewrites of 3.2.4,
+4.6, 11.4.2, and 11.5 needed to implement a Suppress solution. It's at least
+twice as much wording as Steve has (and that includes rewriting wording that
+only exists in my meeting notes). Steve's solution is much closer to the
+original intent, and I think that the one thing that's rather wordy can be
+simplified.
+
+> I vote yes for the rest of the AI.
+
+Like Tuck, I'm rather mystified by this. At least half of the rest of the AI
+would be have to be redone if predicates changed status, along with AI05-0274-1.
+So please vote Yes or No or Abstain. (Ballot coming in minutes.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 9, 2012  12:51 AM
+
+I've got a concern and an editorial comment about Steve's AI. (Actually, I saw
+more while writing this...)
+
+First, the concern. 6.1.1(31/3) and 6.1.1(35/3) were changed to use "enable",
+which is fine. And "enable" (6.1.1(19/3)) was changed to say "see 11.4.2". But I
+don't see anything in the new 11.4.2 (or the old one, for that matter), there
+ever discusses when a precondition or postcondition is in fact enabled. In
+contrast, there is a massive discussion in 11.4.2 about subtype predicates and
+when they're enabled.
+
+Specifically, 6.1.1(19/3) says:
+
+If required by the Pre, Pre'Class, Post, or Post'Class assertion policies (see
+11.4.2) in effect at the point of a corresponding aspect specification
+applicable to a given subprogram or entry, then the checks for the respective
+preconditions or postconditions are @i(enabled) for that subprogram or entry.
+
+But I don't see where "if required by" is defined. 11.4.2(10/3) might be
+attempting to do this, but it seems too much of a leap from "Check means the
+check is performed" (which is what 11.4.2 says) to "Check means the check is
+enabled" (which is what I hope we're saying here). After all, we never say
+*what's* required in the "if" part here. Maybe the "if" doesn't say quite
+enough: "if {performing checks is }required by the Pre, ...". (If we do that, we
+need a similar fix for 7.3.2(9/3)).
+
+Then, two editorial comments about the following from 11.4.2:
+
+> > Predicate checks are defined to be enabled or disabled for a given
+> > subtype as follows:
+> >   If a subtype is declared by a type_declaration or subtype_declaration
+> >   that includes one or more predicate specifications, then
+> >      - if the applicable assertion policy for at least one of the
+> >        assertion expressions is Check, then predicate checks are
+> >        enabled for the subtype;
+> >      - otherwise, predicate checks are disabled for the subtype [redundant:
+> >        , regardless of whether predicate checking is enabled for any
+> >        other subtypes mentioned in the declaration].
+> >
+> >   Otherwise, if a subtype is defined by a derived type declaration
+> >   then predicate checks are enabled for the subtype if and only if
+> >   predicate checks are enabled for at least one of the parent subtype
+> >   and the progenitor subtypes.
+> >
+> >   Otherwise, if a subtype is created by a subtype_indication then
+> >   predicate checks are enabled for the subtype if and only if
+> >   predicate checks are enabled for the subtype denoted by the
+> >   subtype_mark.
+> >
+> >   Otherwise, predicates checks are disabled for the given subtype.
+> >   [AARM: In this case, no predicate specifications can apply to the subtype
+> >   and so it doesn't typically matter whether predicate checks are enabled.
+> >   This rule does make a difference, however, when determining whether
+> >   predicates checks are enabled for another type when this type is one of
+> >   multiple progenitors. See the "at least one" wording above.]
+
+(1) Why is this in 11.4.2? All of the other assertions have this defined in
+    their own sections (6.1.1(19/3) and 7.3.2(9/3), modulo the previous
+    discussion). Either all of these should be defined in 11.4.2, or this block
+    should go in 3.2.4.
+
+(2) Four paragraphs in a row, at two different levels, starting with
+    "otherwise"! Please, let's not. :-) These are already indented, so they
+    could be bullets, and then we would not need the middle two "otherwise,
+    if"s.
+
+(3) Humm. This last paragraph seems wrong. You could inherit a predicate from a
+    subtype_mark (in a place where only a subtype_mark is allowed), and that
+    would not be covered by the other bullets (in particular, that would not be
+    a subtype_indication). Not certain that can happen (most things allow
+    subtype_indications, but not everything). Are you absolutely certain that
+    there is no possibility of inheriting a predicate here?? It seems risky to
+    me. Maybe we need to say "subtype_indication or subtype_mark" earlier??
+
+(4) This block is followed by the "Implementation Defined" AARM note for "other
+    assertion policies". That either needs to be deleted or moved.
+
+None of this is remotely show stopping; it's all about polishing the wording,
+not changing the intent.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 9, 2012  1:33 AM
+
+Letter Ballot on AI05-0290-1, version 5. [This should have been "6", based on
+the description in the next paragraph - Editor.]
+
+This is the version of the AI as Steve posted it today (and possibly some
+editorial improvements as suggested by me and Geert, no semantic changes).
+
+___ Approve AI with editorial changes.
+
+___ Reject AI with comments __________________________________.
+
+___ Abstain.
+
+Please vote early and often. Well, at least early. I need to tell Joyce when the
+Standard will be ready tonight (that's Friday night).
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, March 9, 2012  4:23 AM
+
+Where is it?  Not in the database.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 9, 2012  4:30 AM
+
+> Are we sure we want predicates-as-assertions? This is not something we
+> can change later.
+
+Well we can make any changes we like later, for instance, add another aspect so
+that constraint error is raised, and add another checking policy to get
+predicates-as-constraints in effect. These are minor issues anyway (applying
+only in the case where a predicate fails)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 9, 2012  4:32 AM
+
+> I think an implementor could certainly add a "Suppress(Predicate_Check)"
+
+or the ARG can add this to the language later :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 9, 2012  4:41 AM
+
+> I actually don't see any model of Assertion_Policy that could work for
+> both shared generics and duplicated generics, short of making it
+> implementation-defined, which is unpleasant at best
+
+I think it's fine to make it impl-defined, the impact on user code is negligible
+even theoretically, and in practice it won't make any difference at all.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 9, 2012  4:41 AM
+
+> Letter Ballot on AI05-0290-1, version 5.
+...
+> _X__ Approve AI with editorial changes.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, March 9, 2012  8:01 AM
+
+> Letter Ballot on AI05-0290-1, version 5.
+
+Was there supposed to be an attachment?
+
+I am voting "yes" presuming you made the edits you described.
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, March 9, 2012  9:22 AM
+
+I understand now that the attachment called v12 is actually v5. Why does 12
+equal 5?
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, March 9, 2012  10:04 AM
+
+Not sure, perhaps we have switched to using base 3 for AI versions? ;-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, March 9, 2012  10:25 AM
+
+This was due to the multiple versions Erhard and I bounced back and forth during
+the ARG meeting.  Randy only counts revisions that actually make it into the
+config-mgmt system, so with Erhard and my versioning, we are up to version 12+,
+but for Randy, only version 5.
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, March 9, 2012  11:18 AM
+
+Thanks Tuck for that explanation of why 12 = 5. Arned with that knowledge, I can
+now vote.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 9, 2012  11:40 AM
+
+What fuss about 12 and 5, was that anything substantive?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 9, 2012  12:51 AM
+
+> Where is it?  Not in the database.
+
+Sorry, should have been clearer. This is the version that Steve posted to the
+ARG list yesterday 12:25 PM, along with the following editorial comments from
+Geert and me.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 9, 2012  1:17 PM
+
+> >> I understand now that the attachment called v12 is actually v5. Why
+> >> does
+> >> 12 equal 5?
+> >
+> > Not sure, perhaps we have switched to using base 3 for AI versions?
+> > ;-)
+>
+> This was due to the multiple versions Erhard and I bounced back and
+> forth during the ARG meeting.  Randy only counts revisions that
+> actually make it into the config-mgmt system, so with Erhard and my
+> versioning, we are up to version 12+, but for Randy, only version 5.
+
+Right. I'll file at least one version for each discussion period during the
+meeting, so that will be at least two versions. There since have been two more
+drafts. The actual version number won't be known until I actually do this, I
+only know that it will be around 5 or so.
+
+(Joyce needs the Standard ASAP, I doubt she cares about the state of the version
+control system for AIs! So for now, I'm ignoring all of the intermediate
+versions and focusing only on the final result; I'll have to fix that after I
+get the Standard done but other tasks are unimportant at the moment.)
+
+****************************************************************
+
+From: Geert Bosch
+Sent: Friday, March 9, 2012  10:05 AM
+
+> Is this even possible with shared generics? I know they are now out of
+> fashion, but this seems to require full duplication.
+
+I think it would work just fine to add a few boolean flags as part of the
+instance data and use these as first boolean test:
+   with Pre => Some_Precondition (...)
+
+would be expanded to
+
+  with Pre => _ignore_pre or else Some_Precondition (...)
+
+where _ignore_pre is the boolean added to the generic during expansion in the
+compiler. A single perfectly predictable test is very cheap, and conforming in
+both semantic effect and spirit.
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, March 9, 2012  11:22 AM
+
+Here is my vote. After all that fuss about 12 and 5, I fear I am abstaining.
+
+> Letter Ballot on AI05-0290-1, version 5.
+>
+> This is the version of the AI as Steve posted it today (and possibly
+> some editorial improvements as suggested by me and Geert, no semantic changes).
+>
+> ___ Approve AI with editorial changes.
+>
+> ___ Reject AI with comments __________________________________.
+>
+> __X_ Abstain.
+
+John (retd)  I'm not sure whether that should be retarded rather than retired.
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Friday, March 9, 2012  11:45 AM
+
+> Letter Ballot on AI05-0290-1, version 5.
+>
+> This is the version of the AI as Steve posted it today (and possibly
+> some editorial improvements as suggested by me and Geert, no semantic changes).
+>
+> X Approve AI with editorial changes.
+
+****************************************************************
+
+From: Geert Bosch
+Sent: Friday, March 9, 2012  12:07 PM
+
+> Letter Ballot on AI05-0290-1, version 5.
+>
+> This is the version of the AI as Steve posted it today (and possibly
+> some editorial improvements as suggested by me and Geert, no semantic changes).
+>
+> _X_ Approve AI with editorial changes.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Friday, March 9, 2012  12:08 PM
+
+Letter Ballot on AI05-0290-1, version 5.
+
+This is the version of the AI as Steve posted it today (and possibly some
+editorial improvements as suggested by me and Geert, no semantic changes).
+
+_X_ Approve AI with editorial changes.
+
+___ Reject AI with comments __________________________________.
+
+___ Abstain.
+
+...
+
+I was originally intending to abstain, as I thought being sometimes like an
+assertion and being sometimes like a constraint were going to be irreconcilable,
+but having read the AI more slowly over lunch it seems to be a sensible
+compromise and spells out what happens in the problem cases, though it's still
+not nice that sometimes violating a subtype predicate causes an Assertion_Error
+and sometimes causes a Constraint_Error.  The ideas about specifying what
+exception is raised are interesting but too late for Ada 2012.  As Randy says,
+presumably after having seen the bigger picture after applying the proposed
+changes, some polishing is still needed, so yes assuming this is done.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, March 9, 2012  12:35 PM
+
+_X__ Approve AI with editorial changes.
+
+___ Reject AI with comments __________________________________.
+
+___ Abstain.
+
+
+I vote to approve with changes.
+
+----
+
+Now about those editorial changes:
+
+Please feel free to clean up "(see 11.4.2)" references that I added. The idea
+(which I may have failed to implement correctly) was to add such a reference
+whenever we refer to predicate checks being enabled or disabled in RM sections
+preceding the point where this notion is defined.
+
+> (1) Why is this in 11.4.2? All of the other assertions have this
+> defined in their own sections (6.1.1(19/3) and 7.3.2(9/3), modulo the
+> previous discussion). Either all of these should be defined in 11.4.2,
+> or this block should go in 3.2.4.
+
+I think you are right - moving this to 3.2.4 would probably make sense (and
+would eliminate some of the forward references). Just my two cents worth; I'm
+leaving this to the editor's discretion.
+
+[That sounds so much better than "I'm dumping this one in Randy's lap"]
+
+> Four paragraphs in a row, at two different levels, starting with
+> "otherwise"! Please, let's not.
+
+I'm leaving this to the editor's discretion.
+
+> This block is followed by the "Implementation Defined" AARM note for
+> "other assertion policies". That either needs to be deleted or moved.
+
+I'm leaving this to the editor's discretion.
+
+> Humm. This last paragraph seems wrong. You could inherit a predicate
+> from a subtype_mark (in a place where only a subtype_mark is allowed),
+> and that would not be covered by the other bullets (in particular,
+> that would not be a subtype_indication). Not certain that can happen
+> (most things allow subtype_indications, but not everything). Are you
+> absolutely certain that there is no possibility of inheriting a predicate here??
+
+The decomposition into subcases is intended to mirror the structure of
+3.2.4(3/3-5/3). Does that answer your question?
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, March 9, 2012  12:45 PM
+
+>> AARM note: This means that an Assertion_Policy pragma that occurs in
+>> a scope enclosing the declaration of a generic unit but not also
+>> enclosing the declaration of a given instance of that generic unit
+>> will not apply to assertion expressions occuring within the given instance.
+> Is this even possible with shared generics? I know they are now out of
+> fashion, but this seems to require full duplication.
+>
+
+Randy Brukardt wrote:
+> The answer is NO; there is no
+> possible way to do any significant sharing with this model.
+
+Geert Bosch wrote:
+> I think it would work just fine to add a few boolean flags as part of
+> the instance data and use these as first boolean test:
+
+I agree with Geert. This rule does introduce some implementation complexity for
+a shared code generics implementation but nothing insurmountable.
+
+The main point here is that we want to treat assertion policy consistently with
+suppression in this respect (although Randy makes a good point that
+suppression-related issues can be dealt with by simply ignoring Suppress pragmas
+and this is not true for Assertion_Policy pragmas).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 9, 2012  1:13 PM
+
+> > Is this even possible with shared generics? I know they are now out
+> > of fashion, but this seems to require full duplication.
+>
+> I think it would work just fine to add a few boolean flags as part of
+> the instance data and use these as first boolean test:
+>    with Pre => Some_Precondition (...)
+>
+> would be expanded to
+>
+>   with Pre => _ignore_pre or else Some_Precondition (...)
+>
+> where _ignore_pre is the boolean added to the generic during expansion
+> in the compiler. A single perfectly predictable test is very cheap,
+> and conforming in both semantic effect and spirit.
+
+I mentioned this possibility yesterday, but dismissed it because of distributed
+overhead.
+
+I wouldn't call it "very cheap", for a number of reasons:
+(1) Accessing instance data is doubly indirect, so it's never "very cheap"
+to access;
+(2) There are something like 12 of these flags, all of which would have to be
+set (at runtime) for every instance;
+(3) Since we don't know the contents of the body, we'd have to set these flags
+for every instance whether there are any assertions in the body or not.
+(4) You'd definitely *not* want to do this for assertions evaluated outside of
+the generic unit (which would be most of them), so the compiler complexity is
+doubled.
+(5) This would not get rid of testing paths, just make even more of them
+inaccessible and thus untestable, so it wouldn't work for some users. (I suppose
+it is possible that the entire notion of shared generics would not work for
+those users, although I have no evidence either way on this.)
+
+Something I didn't think of yesterday is that the flags could be bit-packed, so
+(2) could be made fairly cheap (probably just a single assignment per instance),
+and that would mitigate (2) and (3). But that would complicate (1) further,
+making the check even further from "very cheap".
+
+In any case, I'm not asking for a rule change here; there's obviously a path to
+implementing this "by-the-book", although it is unlikely that I would do that in
+the absence of some customer need. (The typical use cases would never cause any
+significance to how this is done, so I very much doubt that anyone would care
+about this.)
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, March 9, 2012  1:01 PM
+
+> Letter Ballot on AI05-0290-1, version 5.
+>
+> This is the version of the AI as Steve posted it today (and possibly
+> some editorial improvements as suggested by me and Geert, no semantic changes).
+>
+> _X__ Approve AI with editorial changes.
+>
+> ___ Reject AI with comments __________________________________.
+>
+> ___ Abstain.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 9, 2012  1:19 PM
+
+I seem to have forgotten to vote on the ballot I initiated.
+
+> Letter Ballot on AI05-0290-1, version 5.
+>
+> This is the version of the AI as Steve posted it today (and possibly
+> some editorial improvements as suggested by me and Geert, no semantic
+> changes).
+>
+> __Yea hey!!__ Approve AI with editorial changes.
+>
+> ___ Reject AI with comments __________________________________.
+>
+> ___ Abstain.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, March 9, 2012  3:38 PM
+
+> ___ Approve AI with editorial changes.
+>
+> ___ Reject AI with comments __________________________________.
+>
+> _X__ Abstain.
+>
+Not yet fully convinced about predicates...
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, March 9, 2012  4:55 PM
+
+> Letter Ballot on AI05-0290-1, version 5.
+>
+> This is the version of the AI as Steve posted it today (and possibly
+> some editorial improvements as suggested by me and Geert, no semantic changes).
+>
+> _X_ Approve AI with editorial changes.
+>
+> ___ Reject AI with comments __________________________________.
+>
+> ___ Abstain.
+>
+
+I have a few additional (minor) editorial suggestions that I'll mention here
+(but of course my vote is not contingent on these):
+
+> append after 3.8.1(21):
+>
+> If the value of the discriminant governing the variant is not covered
+> by the discrete_choice_list of the variant then Constraint_Error is
+> raised. This rule applies in turn to any further variant that is,
+> itself, included in the component_list of the given variant. This
+> check is performed when an object of a discriminated type is initialized by default.
+
+When describing checks, I think that the RM usually follows a structure like
+"... a check is made that ...." followed by "If this check fails, then...". I
+suggest that the above be rephrased along these lines:
+
+  When an object of a discriminated type is initialized by default, a check is
+  made that the discrete_choice_list of a variant governed by a discriminant
+  covers the discriminant value. If this check fails, then Constraint_Error
+  is raised. This rule applies in turn to...
+
+> AARM note:
+>   Like the checks associated with a per-object constraint, this check
+>   is not performed during the elaboration of a subtype indication.
+>   This check can fail if the discriminant subtype
+>   has a Static_Predicate specified, it also has predicate checking
+>   disabled, and the discriminant governs a variant part which
+>   lacks a "when others" choice.
+
+In the AARM note following that check, I suggest rephrasing the last sentence to
+emphasize that this is a case where the check can fail even though predicate
+checking is disabled:
+
+  This check can fail even when the discriminant subtype has predicate checking
+  disabled, if the discriminant subtype has a Static_Predicate specified and
+  the discriminant governs a variant part which lacks a "when others" choice.
+
+> ------
+> Replace 11.4.2, 10/2 by:
+>
+> ...
+>
+> AARM note: This means that an Assertion_Policy pragma that occurs in a
+> scope enclosing the declaration of a generic unit but not also
+> enclosing the declaration of a given instance of that generic unit
+> will not apply to assertion expressions occuring within the given instance.
+
+occuring => occurring
+
+
+> ------
+> Replace 11.4.2, 10/2 by:
+>
+> ...
+>
+> Predicate checks are defined to be enabled or disabled for a given
+> subtype as follows:
+>    If a subtype is declared by a type_declaration or subtype_declaration
+>    that includes one or more predicate specifications, then
+
+It was a bit of a surprise to me that a subtype_declaration can have more than
+one predicate specification.  Based on talking to Steve, this can only occur if
+there are both a Static_Predicate and a Dynamic_Predicate (which still seems a
+little weird to me).  I wonder if this wording could be revised to reflect that
+possibility more clearly. The current wording makes it sound like there could be
+even more than two predicate specifications present on a declaration (which is
+not the case).  At least an AARM paragraph might be in order.
+
+>       - if the applicable assertion policy for at least one of the assertion
+>         expressions is Check, then predicate checks are enabled for the
+>         subtype;
+>       - otherwise, predicate checks are disabled for the subtype [redundant:
+>         , regardless of whether predicate checking is enabled for any
+>         other subtypes mentioned in the declaration].
+>
+>    Otherwise, if a subtype is defined by a derived type declaration
+>    then predicate checks are enabled for the subtype if and only if
+>    predicate checks are enabled for at least one of the parent subtype
+>    and the progenitor subtypes.
+>
+>    Otherwise, if a subtype is created by a subtype_indication then
+>    predicate checks are enabled for the subtype if and only if
+>    predicate checks are enabled for the subtype denoted by the
+>    subtype_mark.
+>
+>    Otherwise, predicates checks are disabled for the given subtype.
+
+I tend to agree with Randy that the string of "otherwise" paragraphs should be
+put in a different form (such as bullets).
+
+>    [AARM: In this case, no predicate specifications can apply to the subtype
+>    and so it doesn't typically matter whether predicate checks are enabled.
+>    This rule does make a difference, however, when determining whether
+>    predicates checks are enabled for another type when this type is one of
+>    multiple progenitors. See the "at least one" wording above.]
+
+When I first read 'See the "at least one" wording above.' I initially thought it
+might be referring to the first of the two bulleted paragraphs above ("at least
+one of the assertion expressions"), then spotted the "at least one" in the other
+paragraph.  Perhaps revise the AARM sentence to clarify this (such as 'See the
+"at least one of the parent subtype" wording above.').
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, March 9, 2012  5:30 PM
+
+Gary - Thanks for the careful reading - you caught some good ones.
+
+I agree with all of Gary's comments and suggested editorial improvements except
+for one:
+
+>> AARM note:
+>>   Like the checks associated with a per-object constraint, this check
+>>   is not performed during the elaboration of a subtype indication.
+>>   This check can fail if the discriminant subtype
+>>   has a Static_Predicate specified, it also has predicate checking
+>>   disabled, and the discriminant governs a variant part which
+>>   lacks a "when others" choice.
+>
+> In the AARM note following that check, I suggest rephrasing the last
+> sentence to emphasize that this is a case where the check can fail
+> even though predicate checking is disabled:
+>
+>   This check can fail even when the discriminant subtype has predicate checking
+>   disabled, if the discriminant subtype has a Static_Predicate specified and
+>   the discriminant governs a variant part which lacks a "when others" choice.
+
+I think the point of this AARM note is to demonstrate the motivation for the
+check by describing a scenario in which the check can fail.
+
+Gary's point is, I think, that users might be surprised to discover that a
+static_predicate specification can have an effect on a program even if predicate
+checking is disabled for the subtype in question.
+
+I agree on both counts (a disabled predicate can have an effect and it is
+somewhat surprising), but that's not the point of this note.
+
+I think the original wording seems more like an explanation of why this check is
+needed.
+
+Gary - please correct me if I misinterpreted your comments.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, March 9, 2012  6:27 PM
+
+Steve Baird wrote, in response to one of my comments:
+
+...
+> I think the original wording seems more like an explanation of why
+> this check is needed.
+>
+> Gary - please correct me if I misinterpreted your comments.
+
+You're right, I got a little confused on that one.  I think that part of what
+threw me off is that the wording makes it sound like this check would only fail
+if predicate checking is disabled.  Strictly speaking that's true, because if
+the predicate has checking enabled, then it would fail another check first (on
+the conversion of the value to the discriminant's subtype) and never get to this
+check.  But if the check *were* to be performed (;-), then it would fail
+independently of predicate checking being enabled or disabled.  Maybe it would
+help to say "This check is needed (and will fail) in the case where ...", but I
+suppose it's OK as is.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, March 9, 2012  6:48 PM
+
+> predicate checking being enabled or disabled.  Maybe it would help to
+> say "This check is needed (and will fail) in the case where ...", but
+> I suppose it's OK as is.
+
+Correction: that should be "and can fail", not "and will fail"!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, March 10, 2012  10:16 AM
+
+> Letter Ballot on AI05-0290-1, version 5.
+>
+> This is the version of the AI as Steve posted it today (and possibly
+> some editorial improvements as suggested by me and Geert, no semantic changes).
+>
+> ___ Approve AI with editorial changes.
+
+_X_ Approve AI with editorial changes.
+
+> ___ Reject AI with comments __________________________________.
+>
+> ___ Abstain.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, March 12, 2012  8:50 AM
+
+Letter Ballot on AI05-0290-1, version 5.
+
+This is the version of the AI as Steve posted it today (and possibly some
+editorial improvements as suggested by me and Geert, no semantic changes).
+
+ __X_ Approve AI with editorial changes.
+
+ ___ Reject AI with comments __________________________________.
+
+ ___ Abstain.
+
+A suggested editorial on the rewrite of 4.9.1(10/3):
+(twice) make "checking is enabled" into "checks are enabled" to match the
+diction of the remainder of the RM.
+
+A "must" editorial on the same para: the reference is 11.4.2, not 11.2.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 13, 2012  8:22 PM
+
+> [untracked - way off-topic for this TN]
+
+I took the liberty of CC'ing the ARG on this one. [The original message was
+a private one from Steve Baird - Editor.]
+
+>> What about a situation where there is a Pre on a declaration, and
+>> then the completion is a renaming as body of a subprogram that *also*
+>> has a Pre on it?  Is this like inheritance, or is this illegal, or is
+>> the semantics like a wrapper?  I guess in general renaming-as-body is
+>> like a wrapper, so probably can leave it at that for the purposes of
+>> Pre/Post as well.
+>>
+>
+>
+> I think you are right, but it made me wonder about a couple of
+> spectacularly unimportant corner cases.
+
+I think your brain consists only of corners... ;-)
+
+> declare
+> package Pkg0 is
+> type T0 is tagged null record;
+> function Is_Dandy (X0 : T0'Class) return Boolean; end Pkg0;
+>
+> package Pkg1 is
+> type T1 is new Pkg0.T0 with null record; procedure Op1 (X1 : T1) with
+> Pre'Class => Pkg0.Is_Dandy (X1); procedure Op1_Ren (X1 : T1) renames
+> Op1;
+>
+> procedure Op2 (X1 : T1);
+> end Pkg1;
+>
+> package Pkg2 is
+> type T2 is new Pkg1.T1 with null record;
+>
+> overriding procedure Op1_Ren (X2 : T2);
+> -- inherits Pre'Class?
+
+Yes, since a dispatching call through the Op1_Ren of T1 checks Is_Dandy.
+
+>
+> overriding procedure Op2 (X2 : T2) renames Op1;
+> -- inherits Pre'Class ?
+
+This is a new dispatching operation, so this question is harder to answer, but I
+think, it has the same properties as the implicitly declared Op1, and we know
+that one is expecting that Is_Dandy has been checked before arriving at the
+inherited body.
+
+> end Pkg2;
+>
+> Which of the ops in Pkg2 have Is_Dandy Pre'Class preconditions? What
+> about Pkg2.Op1_Ren?
+
+The implicit Op1, as well as the two explicit ops, I would say.
+
+> ====
+>
+> package Outer is is
+> type T1 is tagged null record;
+> package Inner is
+> type T2 is tagged null record;
+> procedure Mixed (X1 : T1; X2 : T2)
+> with Pre'Class => ...;
+> end Inner;
+> procedure Mixed_Ren (...) renames Inner.Mixed; end Outer;
+>
+> Does Outer.Mixed_Ren have a Pre'Class which is inherited by
+> descendants of Outer.T1?
+
+Yes, I would say so.  Again, the body of Inner.Mixed is expecting the given
+precondition to have been checked.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, March 17, 2012  5:00 PM
+
+...
+> > append after 3.8.1(21):
+> >
+> > If the value of the discriminant governing the variant is not
+> > covered by the discrete_choice_list of the variant then
+> > Constraint_Error is raised. This rule applies in turn to any further
+> > variant that is, itself, included in the component_list of the given
+> > variant. This check is performed when an object of a discriminated
+> > type is initialized by default.
+>
+> When describing checks, I think that the RM usually follows a
+> structure like "... a check is made that ...." followed by "If this
+> check fails, then...".
+> I suggest that the above be rephrased along these lines:
+>
+>   When an object of a discriminated type is initialized by default, a check is
+>   made that the discrete_choice_list of a variant governed by a discriminant
+>   covers the discriminant value. If this check fails, then Constraint_Error
+>   is raised. This rule applies in turn to...
+
+That's quite correct, but it is *very* important that this not be described as a
+"check". This is *not* suppressable/ignorable; it's always made (logically).
+Note that the similar case statement rule is simply described as part of the
+Dynamic Semantics of case statements; we need to do the same here. (I also
+rearranged the words a bit to clarify the meaning.)
+
+    When an object of a discriminated type is initialized by default,
+    Constraint_Error is raised if no discrete_choice_list of a variant that is
+    governed by a discriminant covers the value of the discriminant. This rule
+    applies in turn to any further variant that is, itself, included in the
+    component_list of the given variant.
+
+I still find the variants and discriminants here to be confusing. And there is
+no description of what variant we are talking about. So introduce some letters:
+
+    When an object of a discriminated type T is initialized by default,
+    Constraint_Error is raised if no discrete_choice_list of a variant V of T
+    that is governed by a discriminant D covers the value of D. This rule
+    applies in turn to any further variant that is, itself, included in the
+    component_list of V.
+
+Humm. The "covers" part to hangs oddly, move it (and that allows us to get rid
+of D):
+
+    When an object of a discriminated type T is initialized by default,
+    Constraint_Error is raised if no discrete_choice_list of a variant V of T
+    covers the value of the discriminant that governs V. This rule applies in
+    turn to any further variant that is, itself, included in the component_list
+    of V.
+
+> > AARM note:
+> >   Like the checks associated with a per-object constraint, this check
+> >   is not performed during the elaboration of a subtype indication.
+> >   This check is needed (and can fail) in the case where the discriminant
+> >   subtype has a Static_Predicate specified, it also has predicate checking
+> >   disabled, and the discriminant governs a variant part which
+> >   lacks a "when others" choice.
+
+Gotta eliminate "check" here, as well. Probably also note that this is not a
+check, and say something about the range check case:
+
+AARM implementation note:
+   This is not a "check"; it cannot be suppressed. However, in most cases it is
+   not necessary to generate any code to raise this exception. A test is needed
+   (and can fail) in the case where the discriminant subtype has a
+   Static_Predicate specified, it also has predicate checking disabled, and the
+   discriminant governs a variant part which lacks a "when others" choice.
+
+   The test also could fail for a static discriminant subtype with range
+   checking suppressed and the discriminant governs a variant part which lacks a
+   "when others" choice. But execution is erroneous if a range check that would
+   have failed is suppressed (see 11.5), so an implementation does not have to
+   generate code to check this case. (An unchecked failed predicate does not
+   cause erroneous execution, so the test is required in that case.)
+
+   Like the checks associated with a per-object constraint, this test is not
+   made during the elaboration of a subtype indication.
+End AARM Implementation Note.
+
+The reason for adding the second paragraph is that given the emphasis on this
+not being a check, it's important to explain why this does not require any
+change to an implementation for range checks. (It's also important to explain
+that this test is not inconsistent (runtime incompatible), because the program
+already was erroneous, so even if the implementation adds the test and raises
+Constraint_Error, that was already allowed in the past.)
+
+> > ------
+> > Replace 11.4.2, 10/2 by:
+> >
+> > ...
+> >
+> > Predicate checks are defined to be enabled or disabled for a given
+> > subtype as follows:
+> >    If a subtype is declared by a type_declaration or subtype_declaration
+> >    that includes one or more predicate specifications, then
+>
+> It was a bit of a surprise to me that a subtype_declaration can have
+> more than one predicate specification.  Based on talking to Steve,
+> this can only occur if there are both a Static_Predicate and a
+> Dynamic_Predicate (which still seems a little weird to me).  I wonder
+> if this wording could be revised to reflect that possibility more clearly.
+> The current wording makes it sound like there could be even more than
+> two predicate specifications present on a declaration (which is not
+> the case).  At least an AARM paragraph might be in order.
+
+I'm not sure why we care. If it contains two predicate specifications, it surely
+contains one, and that's all we care about here (presence or absence). I think
+this is just a case of Steve being overly pedantic. So just say:
+
+    If a subtype is declared by a type_declaration or subtype_declaration
+    that includes a predicate specification, then
+
+Then, the "at least one" wording in the next item has to go. But I think that's
+OK; you can't put a Assertion_Policy pragma in the middle of an aspect
+specification (no semicolons there), so it is whatever policy applies to the
+entire (sub)type declaration is all that matters. (And there is no inheritance
+of policies for subtypes, unlike for pre- and postconditions.) So this wording
+can be a lot simpler:
+
+   - if the applicable assertion policy for the declaration
+     is Check, then predicate checks are enabled for the subtype;
+
+(remembering that this immediately follows the previous "lead-in", so the
+declaration being talked about is obvious).
+
+...
+> >    [AARM: In this case, no predicate specifications can apply to the subtype
+> >    and so it doesn't typically matter whether predicate checks are enabled.
+> >    This rule does make a difference, however, when determining whether
+> >    predicates checks are enabled for another type when this type is one
+> >    of multiple progenitors. See the "at least one" wording above.]
+>
+> When I first read 'See the "at least one" wording above.' I initially
+> thought it might be referring to the first of the two bulleted
+> paragraphs above ("at least one of the assertion expressions"), then
+> spotted the "at least one" in the other paragraph.  Perhaps revise the
+> AARM sentence to clarify this (such as 'See the "at least one of the
+> parent subtype"
+> wording above.').
+
+This is no longer an issue because the wording that confused you is gone.
+Best possible solution. :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, March 18, 2012  10:33 PM
+
+Well, as expected, I saw some issues when adding this wording to the
+Standard:
+[(3) is particularly sticky. Please review...]
+
+(1) The proposed grammar change in 2.8(3) is:
+
+  pragma_argument_association ::=
+     [pragma_argument_identifier =>] name
+   | [pragma_argument_identifier =>] expression
+   | [pragma_argument_aspect_mark =>] name
+   | [pragma_argument_aspect_mark =>] expression
+
+This is ambiguous in the case of an unprefixed name or expression. (I realize
+this grammar is ambiguous in a bunch of other ways as well, but they're not so
+obvious. Erhard in particular complained about this elsewhere; his argument
+there certainly applies here as well.) Moreover, we never actually use the
+possibility of an optional aspect_mark anywhere, so this ambiguity isn't even
+necessary.
+
+So I replaced this grammar by:
+
+  pragma_argument_association ::=
+     [pragma_argument_identifier =>] name
+   | [pragma_argument_identifier =>] expression
+   | pragma_argument_aspect_mark =>  name
+   | pragma_argument_aspect_mark =>  expression
+
+Which doesn't have the obvious ambiguity. (I realize that we never use this
+pragma grammar anywhere, as each pragma has it's own grammar. But that's no
+reason for this to be wrong.)
+
+---
+
+(2) The first bullet of the 3.2.4(6/3) change should end with a colon; the
+penultimate bullet should end with a semicolon rather than a period.
+
+---
+
+(3) My rewording of 3.8.1(21.1/3) doesn't work because I confused "variant" and
+"variant_part". (I think Steve did, too, because the wording he had made no
+sense either; we're not interested in variants in this wording.) However, we
+need to exclude this test on variant_parts that appear in variants that aren't
+selected, and that is very hard to word. (Steve copied the old wording for when
+components are included; besides being backwards, this wording isn't clear at
+all and thus is a lousy example to copy.) (It would be nice if we had a term
+like "selected" to describe a variant whose components are included in the
+record value.)
+
+This should read something like:
+
+When an object of a discriminated type T is initialized by default,
+Constraint_Error is raised if no discrete_choice_list of any variant of a
+variant_part of T covers the value of the discriminant that governs the
+variant_part. When a variant_part appears in the component_list of another
+variant V, this test is only applied if the value of the discriminant governing
+V is covered by the discrete_choice_list of V.
+
+[If reviewing this, make sure you put it into the context of 3.8.1(21); that's
+the mistake I made last night. - RLB]
+
+----
+
+(4) 4.9.1(10/3) uses the wording "obeys the predicate", which is not defined (or
+even obvious). (This is old wording, but garbage is still garbage with age. :-)
+I replaced "obeys" with "satisfies" (the defined term).
+
+[Aside: I don't quite see why the checking state ought to matter for "static
+compatibility", as this affects Legality Rules and that seems wrong on the face
+of it. Moreover, the semantics of the (static) predicate doesn't change whether
+or not checking is enabled. But I presume that Steve has some reason that he
+failed to explain, so I've made this change without knowing why.]
+
+----
+
+(5) Oh, crap, the wording for 6.1.1 doesn't come close to the model we intended.
+I have no idea how to fix, but that will have to be done before the Standard
+goes out. See the separate message.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, March 19, 2012  6:38 AM
+
+Good idea!
+
+> (1) The proposed grammar change in 2.8(3) is:
+>
+>   pragma_argument_association ::=
+>      [pragma_argument_identifier =>] name
+>    | [pragma_argument_identifier =>] expression
+>    | [pragma_argument_aspect_mark =>] name
+>    | [pragma_argument_aspect_mark =>] expression
+>
+> This is ambiguous in the case of an unprefixed name or expression. (I
+> realize this grammar is ambiguous in a bunch of other ways as well,
+> but they're not so obvious. Erhard in particular complained about this
+> elsewhere; his argument there certainly applies here as well.)
+> Moreover, we never actually use the possibility of an optional
+> aspect_mark anywhere, so this ambiguity isn't even necessary.
+>
+> So I replaced this grammar by:
+>
+>   pragma_argument_association ::=
+>      [pragma_argument_identifier =>] name
+>    | [pragma_argument_identifier =>] expression
+>    | pragma_argument_aspect_mark =>  name
+>    | pragma_argument_aspect_mark =>  expression
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, March 18, 2012  11:06 PM
+
+The last draft (and I think several others) have the following as the wording
+changes for 6.1.1:
+
+> Replace 6.1.1(19/3) with:
+>
+> If performing checks is required by the Pre, Pre'Class, Post, or
+> Post'Class assertion policies (see 11.4.2) in effect at the point of a
+> corresponding aspect specification applicable to a given subprogram or
+> entry, then the checks for the respective preconditions or
+> postconditions are @i(enabled) for that subprogram or entry.
+>
+> Replace 6.1.1(31/3) with:
+>
+> Upon a call of the subprogram or entry, after evaluating any actual
+> parameters, enabled checks for preconditions are performed as follows:
+>
+> Replace the first sentence of 6.1.1(35/3) with:
+>
+> Upon successful return from a call of the subprogram or entry, prior
+> to copying back any by-copy in out or out parameters, any enabled
+> checks for postconditions are performed.
+>
+> Delete 6.1.1(40/3).
+
+Unfortunately, this wording doesn't seem to come close to the model that we
+discussed previously. I don't know if we really intended to abandon all of the
+ideas of inheritance that we discussed, but I don't think so.
+
+Let me enumerate the problems with this wording:
+
+(1) 6.1.1(35/3) says "any enabled checks". But there is only *one* postcondition
+    check per subprogram -- it combines all of class-wide expressions and the
+    (single) specific expression in a *single* check. If we're talking about
+    checks that are enabled, we can only turn that one check on or off; we can't
+    change the parts of the check. (That's similar to the model for predicates,
+    BTW.) But we have separate policies for Post and Post'Class; moreover we
+    intended the policy of the *original* specification to apply forever. None
+    of that is reflected in the wording or the model.
+
+(2) 6.1.1(31/3) also says "enabled checks". Here, specific and class-wide
+    preconditions are separate checks, so there is no issue with Pre. But the
+    class-wide check also is a *single* check including all of the inherited
+    routines; it evaluates all of the expressions that "apply". Again, the model
+    that the policy of the *original* specification always is used does not
+    appear anywhere.
+
+(3) The original use of "enabled" in 6.1.1(26/3) talks about postcondition
+    *expressions* that are enabled, but that was never clear in the wording of
+    6.1.1(19/3), and is totally lost now. (The new 19/3 wording talks
+    specifically about checks.)
+
+-----------------
+
+There seem to be two ways to fix this.
+
+The first way is to keep to the current model of enabling "checks". That would
+require splitting all of the checks into separate checks for each expression,
+which then could be enabled or disabled separately. There are two problems with
+this strategy:
+A: there is no fix at all for (3), which is only interested in expressions;
+B: pretty much all of the Dynamic Semantics section of 6.1.1 would
+have to be redone. In particular, I recall Erhard and I having a lengthy
+discussion about ordering of postcondition checks, which is not a problem since
+there is only one (and the order of 1 thing isn't very interesting!). Changing
+that would require changing quite a bit of wording.
+
+The second way is to change 6.1.1(19/3) to talk about enabling or disabling
+*expressions*, not *checks*. This brings up the problem of how to talk about
+expressions that aren't enabled. One possibility is to say that for an
+expression that is not "enabled", when it is evaluated, the result is True and
+nothing else is evaluated. Then all of the checking wording can be left alone.
+Alternatively, we could insert "enabled" strategically into the checking
+wording. That's probably a better plan.
+
+----
+
+Attempting to follow this plan would require the following changes to Draft 15:
+
+Replace 6.1.1(19/3) with:
+
+If performing checks is required by the Pre, Pre'Class, Post, or Post'Class
+assertion policies (see 11.4.2) in effect at the point of a corresponding aspect
+specification applicable to a given subprogram or entry, then the respective
+precondition or postcondition expressions are considered @i(enabled).
+
+AARM Note: If a class-wide precondition or postcondition expression is enabled,
+it remains enabled when inherited, even if the policy in effect is Ignore for
+the inheriting callable entity.
+
+[This is the model we wanted for these, I believe (see the minutes).]
+
+Replace 6.1.1(31/3) with:
+
+Upon a call of the subprogram or entry, after evaluating any actual parameters,
+precondition checks are performed as follows:
+
+[The model is that checks are always performed, but only enabled expressions are
+evaluated, so the check might be trivial.]
+
+Modify 6.1.1(32/3):
+
+The specific precondition check begins with the evaluation of the specific
+precondition expression that applies to the subprogram or entry{, if it is
+enabled}; if the expression evaluates to False, Assertions.Assertion_Error is
+raised{; if the expression is not enabled, the check succeeds}.
+
+Modify 6.1.1(33/3):
+
+The class-wide precondition check begins with the evaluation of any {enabled}
+class-wide precondition expressions that apply to the subprogram or entry. If
+and only if all the class-wide precondition expressions evaluate to False,
+Assertions.Assertion_Error is raised.
+
+Modify 6.1.1(35/3):
+
+[If the assertion policy in effect at the point of a subprogram or entry
+declaration is Check, then upon]{Upon} successful return from a call of the
+subprogram or entry, prior to copying back any by-copy in out or out parameters,
+the postcondition check is performed. This consists of the evaluation of
+[the]{any enabled} specific and class-wide postcondition expressions that apply
+to the subprogram or entry. If any of the postcondition expressions evaluate to
+False, then Assertions.Assertion_Error is raised. The postcondition expressions
+are evaluated in an arbitrary order, and if any postcondition expression
+evaluates to False, it is not specified whether any other postcondition
+expressions are evaluated. The postcondition check{,}[ and] constraint checks{,
+and predicate checks} associated with copying back in out or out parameters are
+performed in an arbitrary order.
+
+[Note: The precondition checks are missing from the last sentence; I fixed that
+in Invariants but not here.]
+
+Delete 6.1.1(40/3).
+
+
+Similar changes would need to be done for Invariants.
+
+Is this OK? Is there a better idea out there?
+
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, March 19, 2012  6:33 AM
+
+A fix that goes back to the diction of the reviewed RM would be:
+
+"then the checks for the respective preconditions or postconditions are
+@i(enabled)" -> "then the respective preconditions or postconditions are
+@i(enabled)"
+
+"enabled checks for preconditions" -> "checks for enabled preconditions"
+
+"enabled checks for postconditions" -> "checks for enabled postconditions"
+
+(The plural for checks in 31/3 and 40/3 was also in the reviewed RM.)
+
+I would actually prefer the change that stopped calling the evaluation of
+multiple enabled preconditions a single check and then stay with the "enabled
+checks" diction, but the above is the minimal change to fix the inconsistency.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 19, 2012  9:06 AM
+
+> Unfortunately, this wording doesn't seem to come close to the model
+> that we discussed previously. I don't know if we really intended to
+> abandon all of the ideas of inheritance that we discussed, but I don't think so.
+
+I'm not sure I agree with you.  For the subtype predicate, it seemed important
+for it to be all on or all off, because we certainly want a single complete
+predicate used for things like membership, and it was too confusing in my view
+to have two different definitions of the overall "predicate."
+
+For pre/postconditions, I don't see the justification for that.  Each
+pre/postcondition can be independently turned on or off without any real
+definitional problem.  So long as the compiler knows which ones are on and which
+ones are off, there isn't any danger of erroneousness.  And I would say it is
+determined where the explicit aspect clause appears, not where it is inherited.
+What really matters is that when you get to the subprogram body, you know which
+ones have been enforced, and that shouldn't depend on whether you were called
+through the original subprogram or the implicitly-declared inherited one.
+
+I may be missing part of your point, but it seems that we can use "enabled" for
+particular preconditions/postconditions, and then assemble the overall "check"
+from the enabled ones.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 19, 2012  11:33 AM
+
+You obviously missed my point, because you agreed completely with me (and the
+last part suggests using wording like that I proposed at the end of the
+message).
+
+My point is simply that the definition of pre- and postcondition checks is that
+there is only *one* check which is the combination of all of the pre- and
+postcondition expressions. The wording above seems to imply that there are
+multiple checks that can be controlled individually; moreover, the wording of
+19/3 suggests that the checks are on or off based on the last declaration (or
+something like that, I can't really tell).
+
+We obviously never considered this wording in context (I know I never did), and
+it simply doesn't make any sense in that context.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 19, 2012  11:39 AM
+
+> A fix that goes back to the diction of the reviewed RM would be:
+>
+> "then the checks for the respective preconditions or postconditions
+> are @i(enabled)" -> "then the respective preconditions or
+> postconditions are @i(enabled)"
+>
+> "enabled checks for preconditions" -> "checks for enabled
+> preconditions"
+>
+> "enabled checks for postconditions" -> "checks for enabled
+> postconditions"
+>
+> (The plural for checks in 31/3 and 40/3 was also in the reviewed RM.)
+
+Sure, that's fine. But not for 35/3, as you have above. It simply makes no
+sense.
+
+And please keep in mind that "precondition" is ambiguous: it could mean
+"precondition expression" or "precondition check" or something else altogether.
+I'd rather be clear.
+
+> I would actually prefer the change that stopped calling the evaluation
+> of multiple enabled preconditions a single check and then stay with
+> the "enabled checks" diction, but the above is the minimal change to
+> fix the inconsistency.
+
+I understand that you'd prefer multiple checks, and I might, too, if today
+wasn't the deadline for producing the Standard. But rewriting the entire Dynamic
+Semantics section on the last afternoon is a non-starter.
+
+The bigger problem is that your "minimal change" doesn't fix anything. I cannot
+get from your suggestion above to the notion that the checks are always
+performed, but the expressions themselves may be on or off. And I can't quite
+see how the "always on if originally on" model falls out from this wording,
+either.
+
+Anyway, we're out of time; there's no time for discussion. We're going to have
+to make a hard choice right now (see next message).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 19, 2012  12:07 PM
+
+Sorry about the ultra-short time to vote on this, but I have to provide the
+finished Standard today. So please vote on the following ballot ASAP:
+
+____ Approve moving forward with the standard using the wording proposed below.
+
+____ Delay the standard for an unknown period to come up with acceptable
+     wording.
+
+
+Vote by 3:00 PM CDT (-6 UTC).
+
+Note that there are no other choices; if you don't vote for moving the standard
+forward, then you are voting against doing so implicitly (because the time will
+run out before there is a solution).
+
+Please note that we have a hard deadline from ISO for submitting the Standard on
+April 1; that requires WG 9 approval and they need  at least a week to vote.
+Thus the deadline for finishing the Standard's wording today (I have at least
+1/2 day of editorial checking to do after final wording approval).
+
+If this vote fails, we'll have to agree on wording and take another vote (with a
+longer deadline); in that case, the completion of the Standard will be delayed
+at least 3-4 days and more likely over a week. I have no idea what will happen
+if we miss the deadline (and I don't want to find out).
+
+I wouldn't call this vote if I wasn't confident that the following wording
+reflects our intent accurately, but it is significantly different than the old
+wording (which did not, in my view, reflect the intent at all).
+
+[Editorial comments are welcome, otherwise, this is an up or down vote.]
+
+                        Randy Brukardt.
+
+----------------
+
+Following are the significant wording changes from the v7 posted Saturday
+(consider this vote an approval for those changes as well):
+
+Add after 3.8(21):
+
+When an object of a discriminated type T is initialized by default,
+Constraint_Error is raised if no discrete_choice_list of any variant of a
+variant_part of T covers the value of the discriminant that governs the
+variant_part. When a variant_part appears in the component_list of another
+variant V, this test is only applied if the value of the discriminant governing
+V is covered by the discrete_choice_list of V.
+
+[Reword so this is not a "check"; reword so the test is on "variant_part"s and
+not "variant"s.]
+
+---
+
+Replace 6.1.1(19/3) with:
+
+If performing checks is required by the Pre, Pre'Class, Post, or Post'Class
+assertion policies (see 11.4.2) in effect at the point of a corresponding aspect
+specification applicable to a given subprogram or entry, then the respective
+precondition or postcondition expressions are considered @i(enabled).
+
+AARM Note: If a class-wide precondition or postcondition expression is enabled,
+it remains enabled when inherited, even if the policy in effect is Ignore for
+the inheriting callable entity.
+
+Replace 6.1.1(31/3) with:
+
+Upon a call of the subprogram or entry, after evaluating any actual parameters,
+precondition checks are performed as follows:
+
+[The model is that checks are always performed, but only enabled expressions are
+evaluated, so the check might be trivial.]
+
+Modify 6.1.1(32/3):
+
+The specific precondition check begins with the evaluation of the specific
+precondition expression that applies to the subprogram or entry{, if it is
+enabled}; if the expression evaluates to False, Assertions.Assertion_Error is
+raised{; if the expression is not enabled, the check succeeds}.
+
+Modify 6.1.1(33/3):
+
+The class-wide precondition check begins with the evaluation of any {enabled}
+class-wide precondition expressions that apply to the subprogram or entry. If
+and only if all the class-wide precondition expressions evaluate to False,
+Assertions.Assertion_Error is raised.
+
+Modify 6.1.1(35/3):
+
+[If the assertion policy in effect at the point of a subprogram or entry
+declaration is Check, then upon]{Upon} successful return from a call of the
+subprogram or entry, prior to copying back any by-copy in out or out parameters,
+the postcondition check is performed. This consists of the evaluation of
+[the]{any enabled} specific and class-wide postcondition expressions that apply
+to the subprogram or entry. If any of the postcondition expressions evaluate to
+False, then Assertions.Assertion_Error is raised. The postcondition expressions
+are evaluated in an arbitrary order, and if any postcondition expression
+evaluates to False, it is not specified whether any other postcondition
+expressions are evaluated. The postcondition check{,}[ and] constraint checks{,
+and predicate checks} associated with copying back in out or out parameters are
+performed in an arbitrary order.
+
+[Note: The precondition checks are missing from the last sentence; I fixed that
+in Invariants but not here.]
+
+Delete 6.1.1(40/3).
+
+[Reword to talk about enabling "expressions" not "checks", so the intended
+piece-meal enabling works without massive rewording.]
+
+---
+
+Modify 7.3.2(9/3):
+
+If one or more invariant expressions apply to a type T[, and the assertion
+policy (see 11.4.2) at the point of the partial view declaration for T is
+Check,] then an invariant check is performed at the following places, on the
+specified object(s):
+
+Add before 7.3.2(21/3):
+
+If performing checks is required by the Invariant or Invariant'Class assertion
+policies (see 11.4.2) in effect at the point of  corresponding aspect
+specification applicable to a given type, then the respective invariant
+expression are considered @i(enabled).
+
+AARM Note: If a class-wide invariant expression is enabled, it remains enabled
+when inherited, even if the policy in effect is Ignore for the inheriting type.
+
+[This is really only important for 'Class expressions; they need to be checked
+based on their original checking state (that is, always on or always off) -
+otherwise dispatching provides a hole in the checking. They "apply" to all
+derived types, and are included in those type's checks, so we can't "enable"
+checks without significant rewording.]
+
+Modify 7.3.2(21/3):
+
+The invariant check consists of the evaluation of each {enabled} invariant
+expression that applies to T, on each of the objects specified above. If any of
+these evaluate to False, Assertions.Assertion_Error is raised at the point of
+the object initialization, conversion, or call. If a given call requires more
+than one evaluation of an invariant expression, either for multiple objects of a
+single type or for multiple types with invariants, the evaluations are performed
+in an arbitrary order, and if one of them evaluates to False, it is not
+specified whether the others are evaluated. Any invariant check is performed
+prior to copying back any by-copy in out or out parameters. Invariant checks,
+any postcondition check, and any constraint or predicate checks associated with
+in out or out parameters are performed in an arbitrary order.
+
+[Note that the addition of "predicate checks" here was done in a previous AI,
+approved in Kemah.]
+
+---
+
+[I've looked over the rest of the wording and did not see any problems yet, but
+that might change when I actually go to insert it. I hope not. - RLB]
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Monday, March 19, 2012  12:16 PM
+
+> Sorry about the ultra-short time to vote on this, but I have to provide the
+> finished Standard today. So please vote on the following ballot ASAP:
+>
+>_X__ Approve moving forward with the standard using the wording proposed below.
+>
+>____ Delay the standard for an unknown period to come up with acceptable
+>     wording.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 19, 2012  12:17 PM
+
+> Sorry about the ultra-short time to vote on this, but I have to
+> provide the finished Standard today. So please vote on the following ballot ASAP:
+>
+> __x__ Approve moving forward with the standard using the wording
+> proposed below.
+>
+> ____ Delay the standard for an unknown period to come up with
+> acceptable wording.
+
+(unlike most of our letter ballots, this one seems like one of those surveys
+that political parties word carefully to ensure the desired result :-))
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 19, 2012  12:25 PM
+
+> Sorry about the ultra-short time to vote on this, but I have to
+> provide the finished Standard today. So please vote on the following ballot ASAP:
+>
+> __X__ Approve moving forward with the standard using the wording
+> proposed below.
+>
+> ____ Delay the standard for an unknown period to come up with
+> acceptable wording.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Monday, March 19, 2012  12:27 PM
+
+> Sorry about the ultra-short time to vote on this, but I have to
+> provide the finished Standard today. So please vote on the following ballot ASAP:
+>
+> __X__ Approve moving forward with the standard using the wording
+> proposed below.
+>
+> ____ Delay the standard for an unknown period to come up with
+> acceptable wording.
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Monday, March 19, 2012  12:39 PM
+
+> [...] please vote on the following ballot ASAP:
+>
+> X Approve moving forward with the standard using the wording proposed
+> below.
+>
+> ____ Delay the standard for an unknown period to come up with
+> acceptable wording.
+
+****************************************************************
+
+From: Geert Bosch
+Sent: Monday, March 19, 2012  12:55 PM
+
+> Sorry about the ultra-short time to vote on this, but I have to
+> provide the finished Standard today. So please vote on the following ballot ASAP:
+>
+> _X__ Approve moving forward with the standard using the wording
+> proposed below.
+>
+> ____ Delay the standard for an unknown period to come up with
+> acceptable wording.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 19, 2012  1:12 PM
+
+> Sorry about the ultra-short time to vote on this, but I have to
+> provide the finished Standard today. So please vote on the following ballot ASAP:
+>
+> __X__ Approve moving forward with the standard using the wording
+> proposed below.
+>
+> ____ Delay the standard for an unknown period to come up with
+> acceptable wording.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, March 19, 2012  1:27 PM
+
+_X__ Approve moving forward with the standard using the wording proposed below.
+
+Note:  I didn't read the proposed wording.
+If you had instead said "Approve moving forward with the previous
+believed-to-be-wrong wording", I'd have voted for that.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Monday, March 19, 2012  2:31 PM
+
+>Sorry about the ultra-short time to vote on this, but I have to provide
+>the finished Standard today. So please vote on the following ballot
+>ASAP:
+>
+>___X_ Approve moving forward with the standard using the wording
+>proposed below.
+>
+>____ Delay the standard for an unknown period to come up with
+>acceptable wording.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, March 19, 2012  2:38 PM
+
+> Sorry about the ultra-short time to vote on this, but I have to
+> provide the finished Standard today. So please vote on the following ballot ASAP:
+>
+> _X__ Approve moving forward with the standard using the wording
+> proposed below.
+>
+> ____ Delay the standard for an unknown period to come up with
+> acceptable wording.
+
+
+The wording changes look reasonable to me.
+
+Just noting a couple of very minor typos that don't even affect wording:
+
+> ----------------
+>
+> Following are the significant wording changes from the v7 posted
+> Saturday (consider this vote an approval for those changes as well):
+>
+> Add after 3.8(21):
+
+That should be 3.8.1.
+
+> Add before 7.3.2(21/3):
+>
+> If performing checks is required by the Invariant or Invariant'Class
+> assertion policies (see 11.4.2) in effect at the point of
+> corresponding aspect specification applicable to a given type, then
+> the respective invariant expression are considered @i(enabled).
+>
+> AARM Note: If a class-wide invariant expression is enabled, it remains
+> enabled when inherited, even if the policy in effect is Ignore for the
+> inheriting type.
+>
+> [This is really only important for 'Class expressions; they need to be
+> checked based on their original checking state (that is, always on or
+> always off) - otherwise dispatching provides a hole in the checking. They
+> "apply" to all derived types, and are included in those type's checks, so we
+> can't
+
+"those type's" => "those types'"
+
+(But I guess that paragraph in "[]" isn't even AARM text(?), it's just a side
+note from you, so this doesn't need fixing.:-)
+
+> "enable" checks without significant rewording.]
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, March 19, 2012  7:04 PM
+
+> Sorry about the ultra-short time to vote on this, but I have to
+> provide the finished Standard today. So please vote on the following ballot ASAP:
+>
+> __X__ Approve moving forward with the standard using the wording
+> proposed below.
+>
+> ____ Delay the standard for an unknown period to come up with
+> acceptable wording.
+>
+>
+> Vote by 3:00 PM CDT (-6 UTC).
+
+Sorry for being late, I was not reading E-mail until just now.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 19, 2012  8:01 PM
+
+Well, a couple more issues (not very important):
+
+(1) The proposed change in 11.5(25) is:
+
+All_Checks
+Represents the union of all checks; suppressing All_Checks suppresses all
+checks. In addition, an implementation is allowed (but not required) to behave
+as if a pragma Assertion_Policy(Ignore) applies to any region to which pragma
+Suppress(All_Checks) applies.
+
+The problem with this is that assertion checks are, well, checks. So the above
+says that they are both suppressed and ignored, which is certainly not what we
+want (besides making no sense). I added a few words to make the above exclusive:
+
+All_Checks
+Represents the union of all checks; suppressing All_Checks suppresses all checks
+other than those associated with assertions. In addition, an implementation is
+allowed (but not required) to behave as if a pragma Assertion_Policy(Ignore)
+applies to any region to which pragma Suppress(All_Checks) applies.
+
+and added an AARM note to explain (suppressed means erroneous if they fail,
+which is not what we want for assertions).
+
+[Reminder: "assertion checks" here means checks for all of the assertions,
+including preconditions, predicates, etc.]
+
+----
+
+(2) An unrelated bug that I happened to notice:
+
+11.4.2(16/2):
+
+A compilation unit containing a pragma Assert has a semantic dependence on the
+Assertions library unit.
+
+I replaced this by:
+
+A compilation unit containing a {check for an assertion (including a }pragma
+Assert{)} has a semantic dependence on the Assertions library unit.
+
+because it clearly needs to be true of any unit that can raise
+Assertions.Assertion_Error -- that is, any assertion check.
+
+----
+
+(3) The last sentence of 11.4.2(10/3) says:
+
+Note that for subtype predicate aspects (see 3.2.4), even when the applicable
+Assertion_Policy is Ignore, the predicate will still be evaluated as part of
+membership tests and Valid attribute_references, and if static, will still have
+an effect on loop iteration over the subtype, and the selection of
+case_alternatives and variant_alternatives.
+
+The problem here is that there is no such thing as a "case_alternative" or a
+"variant_alternative". These are called "case_statement_alternative" and
+"variant", respectively, and I changed the wording accordingly.
+
+Similarly, the first sentence talks about "argument_association"s, but the
+proper term is "pragma_argument_association"s.
+
+If someone thinks this is overly picky, someone should note that exact matching
+is needed in order for the automatic linking to the appropriate syntax
+production to happen (and also for the by-hand lookup by readers of print
+versions).
+
+----
+
+And that's it; I finally reached the end of this monster.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 19, 2012  8:12 PM
+
+> ...
+> And that's it; I finally reached the end of this monster.
+
+Hurray!  You are the man!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, March 19, 2012  8:17 PM
+
+> Well, a couple more issues (not very important):
+
+Stop fixing bugs in the RM.  Now.  Ship it to ISO and see what happens.
+
+By and by, we'll fix the bugs.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, March 19, 2012  8:19 PM
+
+> Hurray!  You are the man!
+
+Yes!  You are THE man!
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Monday, March 19, 2012  9:36 PM
+
+> And that's it; I finally reached the end of this monster.
+
+An you should feel like St. George!  The Ada community owes you an enormous debt
+for this work and for the heroic last weeks push!
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Tuesday, March 20, 2012  6:05 AM
+
+Thanks Randy for all your good work on this,
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, March 20, 2012  6:18 AM
+
+> Sorry about the ultra-short time to vote on this, but I have to
+> provide the finished Standard today. So please vote on the following
+> ballot ASAP:
+>
+> __X__ Approve moving forward with the standard using the wording
+> proposed below.
+>
+> ____ Delay the standard for an unknown period to come up with
+> acceptable wording.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent