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.
+
+****************************************************************
+