CVS difference for ai05s/ai05-0153-3.txt
--- ai05s/ai05-0153-3.txt 2011/05/10 04:57:53 1.17
+++ ai05s/ai05-0153-3.txt 2011/06/03 02:27:29 1.18
@@ -1,4 +1,4 @@
-!standard 3.2.4(0) 11-05-06 AI05-0153-3/10
+!standard 3.2.4(0) 11-06-02 AI05-0153-3/11
!standard 3.8.1(5)
!standard 3.8.1(8)
!standard 3.8.1(11)
@@ -216,7 +216,7 @@
Dynamic Semantics
-If the Assertion_Policy in effect is Check, then:
+If the assertion policy (see 11.4.2) in effect is Check, then:
Redundant[On every subtype conversion, the predicate of the target subtype is
evaluated, and a check is made that the predicate is True. This includes all
@@ -331,7 +331,7 @@
Add at the end of 4.6(51/2), so subtype conversions raise an exception
on predicate failure:
-If the Assertion_Policy in effect is Check, the predicate of the target subtype
+If the assertion policy (see 11.4.2) in effect is Check, the predicate of the target subtype
is applied to the value and Assertions.Assertion_Error is raised if the result
is False.
@@ -448,12 +448,12 @@
This is unaffected by the Implementation Permissions of 3.2.4,
which allow omission of certain predicate CHECKs (i.e. cases
that raise an exception on predicate failure). Likewise,
-Assertion_Policy => Ignore does not change the semantics of
+assertion policy => Ignore does not change the semantics of
membership tests and 'Valid.
-This means that "S'(X) in S" could be False if Assertion_Policy is Ignore.
-This is similar to suppressing checks (strange things can happen), but
-milder, because suppressing checks can cause erroneous behavior,
+This means that "S'(X) in S" could be False if the assertion policy is
+Ignore. This is similar to suppressing checks (strange things can happen),
+but milder, because suppressing checks can cause erroneous behavior,
whereas here, we get True, or False, or Constraint_Error.
---
@@ -742,7 +742,7 @@
type String1 is new String with
Dynamic_Predicate => String1'First = 1;
-The compiler can deduce (if the Assertion_Policy is Check) that all objects of
+The compiler can deduce (if the assertion policy is Check) that all objects of
type String1 have 'First = 1, and optimize accordingly. It could avoid storing
the lower bound at run time.
@@ -865,7 +865,7 @@
and there are all kinds of permissions to check for invalid data. We don't want
to allow optional evaluation of predicates in such cases. Anyway, an
implementation can always have a mode where it does additional predicate checks.
-An implementation-defined Assertion_Policy could be used for this.
+An implementation-defined assertion policy could be used for this.
However, we do say that the X'Valid is False if the predicate is False.
@@ -890,13 +890,13 @@
----------------
-We are deliberately vague about what "Assertion_Policy in effect" means.
+We are deliberately vague about what "assertion policy in effect" means.
In particular, about precisely WHERE in the source text it matters.
We don't want to impose any implementation burden in this regard,
since in practise, assertion policies will be determined rather
globally, by compiler switches. Unlike for pragma Suppress,
there is no compelling reason to nail this down, since there's
-no erroneousness involved in Assertion_Policy => Ignore.
+no erroneousness involved in assertion policy => Ignore.
In any case, it's not the job of THIS AI to worry about
such matters.
@@ -1028,7 +1028,7 @@
@s8<@i<Dynamic Semantics>>
-If the Assertion_Policy (see 11.4.2) in effect is Check, then:
+If the assertion policy (see 11.4.2) in effect is Check, then:
@xindent<On every subtype conversion, the predicate of the target subtype is
evaluated, and a check is made that the predicate is True. This includes all
@@ -1155,7 +1155,7 @@
After conversion of the value to the target type, if the target subtype is
constrained, a check is performed that the value satisfies this constraint.
If the target subtype excludes null, then a check is
-made that the value is not null. If the Assertion_Policy (see 11.4.2) in effect
+made that the value is not null. If the assertion policy (see 11.4.2) in effect
is Check, the predicate of the target subtype is applied to the value and
Assertions.Assertion_Error is raised if the result is False.
@@ -3491,6 +3491,31 @@
****************************************************************
+From: Bob Duff
+Sent: Tuesday, May 10, 2011 4:15 PM
+
+> OK. It is odd that you can't declare an array subtype using a subtype
+> with a predicate, but you can write the similar aggregate.
+>
+> subtype Smallish is Positive
+> with Static_Predicate => Smallish <= 10;
+>
+> Odd : String(Smallish) -- Illegal.
+
+I considered making that legal, by somehow defining which predicates are
+known to result in a single subrange. But it just didn't seem worth the trouble.
+
+> := (Smallish => ' '); -- Legal.
+>
+> But that doesn't seem critical - it only would work when the predicate
+> should have been written as a range (else the aggregate would violate
+ ^
+ "could", I'd say. Your "Smallish <= 10" predicate doesn't seem at all evil,
+to me, even though it could be expressed as a range. And with the rules as they are,
+you'll HAVE to use a range, if you want to say "String(Smallish)". Oh, well.
+
+****************************************************************
+
From: Randy Brukardt
Sent: Friday, May 06, 2011 8:21 PM
@@ -3813,5 +3838,237 @@
probably lean toward (1) [rather than the current proposal] because it is
simpler and less surprising to users (even if a bit more of a pain), but perhaps
there is something better out there.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, May 10, 2011 3:20 PM
+
+> Two other options come to mind:
+
+Before I answer this, could you please clarify this:
+
+> (1) Always check the predicate in the cases noted.
+
+Which cases noted?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 10, 2011 3:34 PM
+
+> Which cases noted?
+
+Uninitialized object_declarations and allocators (of composite types??) I didn't
+spend very long thinking about the details. There wouldn't be any value to
+requiring it for scalar types, so I think they should be excepted in any case.
+But I still haven't spent very long thinking about the details. ;-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, May 10, 2011 4:05 PM
+
+> In any case, I've fixed up the wording as you indicated for the
+> moment, pending further discussion (I'm giving the author the benefit
+> of the doubt; I don't want to change your intent without discussion).
+
+OK, that seems appropriate.
+
+I think this is the best we can do, although I agree entirely that your
+examples (snipped) illustrates that it's not perfect. But we already knew
+predicates are imperfect. (I hope this issue won't invite us all to go back
+into the mode of "Horrors! Predicates are imperfect! Let's add all kinds
+of restrictions! Let's eliminate the feature altogether!")
+
+You have to be careful that if you have one component with a default_exp,
+then your predicate had better not look at uninit ones. I think often that
+would fall out naturally:
+
+ type T is
+ record
+ Length : Natural := 0;
+ Elements : array (1..Max) of ...; -- yeah, yeah...
+ end record with
+ Predicate => Length <= Max
+ and then (for all X in 1..Length => Is_Good(Elements(X)));
+
+Ada has a serious flaw: There's no way to declare "this type has a meaningful
+default value". So when you read "X : T;" you can't easily tell whether it
+means "I'm going to initialize X later on, before I use it" or "I want to use
+the default value of X, and I'm going to look at it before any explicit
+assignment".
+
+Given this rather unfixable flaw, I think the predicate rule we have is the best
+we can do.
+
+I'm pretty sure the two options you mentioned (snipped), are not an improvement.
+So I think we should stick with what we've got, unless somebody has a
+clearly-better idea.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, May 09, 2011 11:56 PM
+
+As I was finishing up work on AI05-0153-3, I noticed an issue that is mainly
+with the index but might also be a semantic issue.
+
+Some of the wording of AI05-0153-3 says:
+
+"After normal completion and leaving of a subprogram, for each in out or out
+parameter that is passed by reference, the predicate of the subtype of the
+actual is evaluated, and a check is made that the predicate is True."
+
+There is similar wording for preconditions and postconditions, and probably for
+a number of other contract aspects.
+
+I was wondering what the check name to index should be for this. All of the
+language-defined checks have a check name, and these are indexed. By using the
+word "check", this surely appears to be one of these.
+
+But check names exist mainly to serve as input to pragma Suppress. These
+"checks" are controlled separately, via assertion policy; we don't want to
+control these with Suppress.
+
+11.4.2 is careful to not call what pragma Assert does "a check".
+Interestingly, so is the proposed wording for 4.6(51):
+
+"If the Assertion_Policy in effect is Check, the predicate of the target subtype
+is applied to the value and Assertions.Assertion_Error is raised if the result
+is False."
+
+It seems odd at best to avoid the word "check" in text describing what happens
+for a policy of "check".
+
+Anyway, I'm confused. The best plan would be to reword everything involving
+Assertion_Policy to avoid the term "check", but that seems over the top and a
+lot of work.
+
+The second best plan is to define a check name "Assertion_Check" and simply
+mention in 11.5 that you aren't allowed to use Suppress to control those checks
+and use Assertion_Policy instead.
+
+There is no third best plan, perhaps someone has one.
+
+The worst plan is just to ignore the issue and not index these things at all
+(but that is annoying for people trying to find checks, and confusing in the
+operation of pragma Suppress).
+
+Ideas??
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, May 10, 2011 3:29 PM
+
+> The worst plan is just to ignore the issue and not index these things
+> at all (but that is annoying for people trying to find checks, and
+> confusing in the operation of pragma Suppress).
+
+I vote for the "worst plan". There will certainly be an index entry for
+"predicate", so what's the problem?
+
+You say these are not suppressable checks, so why should they be indexed under
+"check" names?
+
+I say, "not sufficiently broken". And if you start doing major rewordings at
+this point, there's a risk of making things worse. If there were a serious bug,
+then it would be worth the risk.
+
+Anyway, check names are already completely broken -- we define their semantics
+only in the AARM, which is supposedly non-normative. That was a deliberate
+decision on my part, which I rationalized by "it's no worse than Ada 83".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 10, 2011 3:52 PM
+
+> You say these are not suppressable checks, so why should they be
+> indexed under "check" names?
+
+Mainly because the only thing indexed under "checks, language defined" are check
+names.
+
+I think it is bad to have checks that are not indexed as checks. And if they are
+not checks, then they should be called something else (and indexed there).
+
+> I say, "not sufficiently broken". And if you start doing major
+> rewordings at this point, there's a risk of making things worse.
+> If there were a serious bug, then it would be worth the risk.
+
+I agree with that. But not indexing these things (whatever they are) seems bad.
+
+Indeed, I think all of the things controlled by the Assertion_Policy ought to be
+indexed somehow -- it's not an obvious list. And so long as these things are
+"checks" they need to be indexed there as well.
+
+I did think of a fourth option last night, which is to index these as "checks,
+language defined, controlled by Assertion_Policy" or something like that. And
+possibly something like: "Assertion_Policy, predicate check".
+
+Since you were the one that created the original useful index, you ought to have
+some idea on how to accomplish that. Not indexing this at all (which it the way
+it is) doesn't seem acceptable.
+
+> Anyway, check names are already completely broken -- we define their
+> semantics only in the AARM, which is supposedly non-normative.
+> That was a deliberate decision on my part, which I rationalized by
+> "it's no worse than Ada 83".
+
+True enough, although it's not quite true, in the sense that the list in
+11.5 is thought to be complete (missing checks have been added, especially by
+Ada 2005). But I agree that there the only real connection between check names
+and actual checks is in the index and in the AARM - neither of which are
+normative.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, May 10, 2011 4:11 PM
+
+> I did think of a fourth option last night, which is to index these as
+> "checks, language defined, controlled by Assertion_Policy" or
+> something like that. And possibly something like: "Assertion_Policy, predicate check".
+
+That sounds like a fine idea.
+
+The index isn't supposed to be language-lawyerly-style normative wording, it's
+supposed to be helpful to people who don't know every jot and tittle of Ada.
+
+> Since you were the one that created the original useful index, you
+> ought to have some idea on how to accomplish that. Not indexing this
+> at all (which it the way it is) doesn't seem acceptable.
+
+Well, I can't get too excited about this issue, so "unacceptable"
+seems too strong. But yeah, your plan above will give us reasonably useful
+index entries, which is good.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, June 2, 2011 9:14 PM
+
+> > I did think of a fourth option last night, which is to index these
+> > as "checks, language defined, controlled by Assertion_Policy" or
+> > something like that. And possibly something like:
+> "Assertion_Policy, predicate check".
+>
+> That sounds like a fine idea.
+>
+> The index isn't supposed to be language-lawyerly-style normative
+> wording, it's supposed to be helpful to people who don't know every
+> jot and tittle of Ada.
+
+In adding these index entries, I happened to notice that 11.4.2(18/3) defines
+the term "assertion policy" to mean the policy specified by the Assertion_Policy
+pragma. However, in most of the new wording, we used "Assertion_Policy" instead.
+(I noticed this because I had two similar index entries next to each other...)
+
+As such, I'm going to fix all of the new wording to use "assertion policy"
+instead of "Assertion_Policy". Not the most important change ever... (I also see
+that there aren't the forward references needed for such a term, not matter how
+it is spelled.)
****************************************************************
Questions? Ask the ACAA Technical Agent