CVS difference for ai12s/ai12-0192-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0192-1.txt

--- ai12s/ai12-0192-1.txt	2016/06/07 01:43:01	1.1
+++ ai12s/ai12-0192-1.txt	2016/06/08 02:16:07	1.2
@@ -176,3 +176,83 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Monday, June 6, 2016 8:52 PM
+
+> ... We could make the new rule apply only if the PT does not have any 
+> "old-style" requires late initialization components -- that would 
+> usually be the case -- but that seems like a bizarre wart. I don't 
+> know what to think there - it's hard to accept making any correct, 
+> legal Ada code silently erroneous.
+
+This is a corner of a corner of a corner case.  I recommend that we document
+the inconsistency, but otherwise not worry about it.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 6, 2016  9:47 PM
+
+That's how I wrote it up.
+
+But, as I said, I'm not sure how I'll vote on this one. I can't remember any
+other case where we introduced an incompatibility that caused correct, legal,
+portable code to become erroneous. (I can think of cases where that happened
+with implementation-defined (non-portable) code, but that's a really different
+thing.) Certainly not outside of the case of a language bug (and there's no
+language bug here).
+
+I'd think that there are certain communities that would be appalled at such a
+thing. (Probably they'd never allow use of the problematic features anyway,
+but the mere presence of such a thing could erode confidence in Ada.)
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, June 7, 2016  2:31 AM
+
+> In writing this up, it occurs to me that this is inconsistent (runtime 
+> incompatible), in that the order that components are initialized could 
+> change.
+
+If this change causes a program to break, then the program already has a bug 
+in it because even without this change the compiler had the option (even if it
+didn't exercise that option) to choose the same initialization order that it
+would choose if this change is adopted.
+
+I suppose you could view this as an incompatibility, but that seems like a
+stretch to me.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 7, 2016  2:29 PM
+
+> If this change causes a program to break, then the program already has 
+> a bug in it because even without this change the compiler had the 
+> option (even if it didn't exercise that
+> option) to choose the same initialization order that it would choose 
+> if this change is adopted.
+
+That's clearly not true as shown in the example I provided.
+
+> I suppose you could view this as an incompatibility, but that seems 
+> like a stretch to me.
+
+I'm mainly worried about the FUD factor of Ada users not knowing if this
+(admittedly unlikely) case appears in their code. That could cause people to
+avoid moving to Ada 2020, and that would be bad.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, June 7, 2016  3:13 PM
+
+If that stops them, then Ada 2020 isn't worth the paper it is written on. ;-)
+
+So long as we are up front about it, I *really* don't see the problem.  This is
+so far down the stack of possible problems relative to the fundamental risk of
+taking on a new version of any compiler, that it is of negligible concern.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent