CVS difference for ai12s/ai12-0289-1.txt
--- ai12s/ai12-0289-1.txt 2018/09/05 21:28:47 1.1
+++ ai12s/ai12-0289-1.txt 2018/09/05 22:03:51 1.2
@@ -39,7 +39,7 @@
end Pack;
-The development version of our compiler rejects (A), saying that it does not
+The development version of our compiler rejects (B), saying that it does not
fully conform to the specification (A).
This appears to be true for this code. The parameter X of (A) is not a
@@ -84,9 +84,10 @@
we were to allow the declarations.
So we conclude that the incompatibility (which is easily fixed by adding
-"not null" to the declaration of parameter X) is the least of the possible
-evils. Explicitly requiring "not null" in this case is better for readers
-AND compilers, and is unlikely to cause many problems.
+"not null" to the declaration of parameter X in both the spec and the body)
+is the least of the possible evils. Explicitly requiring "not null" in this
+case is better for readers AND compilers, and is unlikely to cause many
+problems.
!wording
@@ -107,7 +108,8 @@
---
The incompatibility can be worked around by adding an explicit null exclusion
-to (A).
+to (A) and (B). Note that the definition of full conformance requires explicit
+exclusions on both parts.
!ASIS
@@ -550,3 +552,237 @@
Sounds like a plan to me.
****************************************************************
+
+From: Bob Duff
+Sent: Thursday, August 9, 2018 6:17 AM
+
+> For the record, given the following program:
+>
+> with Ada.Text_IO;
+> procedure TestUgh is
+> -- Tests for GNAT interpretation of AI12-0289-1 problem.
+
+> GNAT 18.1 compiles and gives:
+>
+> --- TestUgh - Conformance of anonymous access types with implicit null
+> exclusions ?? Contraint_Error raised when passing null ??
+> Contraint_Error raised when dispatching on null
+
+As an experiment, I modified GNAT to make this illegal (i.e. procedure PPA
+does not conform to its spec).
+This caused one error in PolyORB, and 10 tests failed (out of 18,000 tests
+in our compiler test suite).
+
+So people are using this feature, and making it illegal will require people to
+change their code, which is currently working just fine.
+
+I admit it's uncomfortable to have a hidden run-time check.
+But it's no worse than having a formal parameter of type Natural, and assigning
+it into a local variable of type Positive. It's basically just a missing
+precondition, of which we have plenty others. In any case, it's not a "privacy
+breakage" -- those are always compile time.
+
+The privacy breakage is a renaming, which seems pretty obscure. IMHO
+compatibility should trump minor privacy breakages. I didn't check, but I'll
+bet none of the above error cases even use renamings at all.
+
+Finally, I consider "not null" to be obsolete.
+"with Predicate => Foo /= null" is better than "not null", and I'd like to
+recommend it to people -- but if we require "not null" in one case, that's
+uncomfortable. (I don't think we're going to say the predicate provides
+conformance!)
+
+I think this is yet another case where "required warning" or "soft error" or
+whatever is the perfect solution. It tells people their code is wrong, and
+they can choose whether to fix it. It nicely defuses the argument between
+"but it's incompatible" and "but it's wrong".
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, August 9, 2018 6:59 AM
+
+This is similar to an incompatibility that was discussed in AI05-0046, and
+was approved. 10 tests out of 18,000 seems like a pretty small
+incompatibility, and the rationale given in AI05-0046 seems to apply here as
+well.
+
+Also, "not null" is not going away, as it appears in many places in the Ada
+standard run-time library.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, August 9, 2018 8:59 AM
+
+> I see various solutions:
+> 1) Make it illegal in Ada 2005+ -- require explicit "not null" on visible
+> declaration.
+>
+> 2) Make it illegal in Ada 2005+ -- require explicit "not null" on both
+> visible and private declarations.
+
+Based on AI05-0046, I now favor (2) over (1). AI05-0046 justifies requiring
+matching(explicit) null exclusions as part of full conformance, and there
+seems no reason to change that for this oddball case.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, August 9, 2018 3:37 PM
+
+...
+> I admit it's uncomfortable to have a hidden run-time check.
+> But it's no worse than having a formal parameter of type Natural, and
+> assigning it into a local variable of type Positive.
+
+It's worse, if only because the implementation is complex. The subtype of the
+specification not being null excluding means that the "hidden check" is not
+going to be checked at all. And it has to be "not null excluding" so that
+static matching works as expected. (This is *not* just about full conformance,
+but also about any other use of static matching, i.e. in subtype conformance
+and even mode conformance [the latter because mode conformance requires
+static matching of anonymous access types].)
+
+To fix that, one would have to invent a subtype that is null excluding at
+runtime and not null excluding at compile-time. Possible I suppose but quite
+annoying.
+
+> It's basically just a missing precondition, of which we have plenty
+> others. In any case, it's not a "privacy breakage" -- those are
+> always compile time.
+>
+> The privacy breakage is a renaming, which seems pretty obscure. IMHO
+> compatibility should trump minor privacy breakages. I didn't check,
+> but I'll bet none of the above error cases even use renamings at all.
+
+I doubt anyone uses these renamings. But in the intervening days, I've been
+working on static matching and I've found it pops up in various other cases,
+including matching of subprograms with formal subprograms in generic
+instances, as well as 'Access.
+
+Moreover, I recall that privacy breaking was virtually unimplementable in the
+Rational Apex technology. PTC isn't represented here, so it's hard to find out
+for sure, but I'd be surprised if that has changed. "Mr. Private" got that
+name for a reason! He would have been very displeased about such a breakage.
+
+So, while I can see the dynamic check being implicit, the static matching has
+to be as if there is no exclusion (because there isn't!!). Is this case worth
+that level of complication?
+
+> Finally, I consider "not null" to be obsolete.
+> "with Predicate => Foo /= null" is better than "not null", and I'd
+> like to recommend it to people -- but if we require "not null" in one
+> case, that's uncomfortable.
+> (I don't think we're going to say the predicate provides
+> conformance!)
+
+This is nonsense, even if I ignore the fact that there is no such thing as
+"Predicate".
+(1) We're talking about an anonymous access type here, and there is no way in
+ Ada 2012 or planned in Ada 2020 to define a predicate for them. You're
+ essentially eliminating a capability. Now, if you wanted to consider
+ anonymous access types obsolete, I would reconsider. ;-)
+(2) Why is "not null" obsolete and not "range" constraints? One can make the
+ same argument that a Static_Predicate is better than a range constraint.
+ (Although you made no such argument above, you just stated it as a fact.
+ No evidence to support that argument.)
+(3) Predicates, like all contracts, are ignored, not suppressed. Thus, they
+ don't provide any information that the compiler can use when they are off,
+ whereas the "not null" does. (Failing a not null check is erroneous when
+ Suppressed.) This difference is testable and definitely is on my list of
+ potential ACATS tests -- "Ignore" tests are still needed in general in
+ the ACATS.
+
+> I think this is yet another case where "required warning" or "soft
+> error" or whatever is the perfect solution. It tells people their
+> code is wrong, and they can choose whether to fix it. It nicely
+> defuses the argument between "but it's incompatible" and "but it's
+> wrong".
+
+Which would double the implementation work for an obscure case. I don't feel
+strongly about what decision we make, but there better be only one.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, August 9, 2018 4:25 PM
+
+> (2) Why is "not null" obsolete and not "range" constraints?
+
+Because scalar types don't force a default value on you, and range contraints
+are not checked on uninitialized variables. That is in, "X : T range 1 .. 10;"
+X might get initialized to the invalid value 999_999, but we don't check that
+it's in 1 .. 10.
+
+I'm think I've mentioned this before on this mailing list, but I could be
+mistaken.
+
+>... One can make the
+> same argument that a Static_Predicate is better than a range constraint.
+
+One can argue that range constraints are now redundant, but I don't see any
+way in which one is better than the other.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, August 9, 2018 4:51 PM
+
+> > (2) Why is "not null" obsolete and not "range" constraints?
+>
+> Because scalar types don't force a default value on you,
+
+That comes from the language and hardly has anything to do with null
+exclusions.
+
+Personally, I think one should only have uninitialized objects by explicit
+declaration (something like A : T := <>") but obviously that's not Ada
+(yet :-). For most cases, they're evil (and especially since the inclusion
+of conditional expressions, generally avoidable).
+
+> ... range contraints are not checked on uninitialized variables.
+> That is in, "X : T range 1 .. 10;" X might get initialized to the
+> invalid value 999_999, but we don't check that it's in 1 .. 10.
+
+Predicates aren't checked on many default-initialized objects, which is a far
+worse bug IMHO. Specifically, they're not checked on any type which has
+specified Default_Value (or Default_Component_Value); these are supposed to
+work similarly to the := components for record types.
+
+> I'm think I've mentioned this before on this mailing list, but I could
+> be mistaken.
+
+Not this particular issue. You insisted on a rule for predicates that I
+consider broken (I haven't tried to get it fixed since it was obviously on
+purpose), and that seems to be in part because of this issue. So I suppose
+we've discussed it tangentially.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, September 5, 2018 4:39 PM
+
+> > I see various solutions:
+> > 1) Make it illegal in Ada 2005+ -- require explicit "not
+> null" on visible declaration.
+> >
+> > 2) Make it illegal in Ada 2005+ -- require explicit "not
+> null" on both visible and private declarations.
+>
+> Based on AI05-0046, I now favor (2) over (1). AI05-0046 justifies
+> requiring matching(explicit) null exclusions as part of full
+> conformance, and there seems no reason to change that for this oddball
+> case.
+
+Actually, the declaration of full conformance requires (2); (1) is not a
+realistic option (it wouldn't make sense to weaken conformance for this
+particular case).
+
+The important issue here is that these two types fail to statically match
+(and keep in mind that anonymous types are always different with each
+occurrence in the source code), and that has consequences for any place that
+is required, including mode and subtype conformance.
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent