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

Differences between 1.6 and version 1.7
Log of other versions for file ai12s/ai12-0092-1.txt

--- ai12s/ai12-0092-1.txt	2014/11/13 04:00:55	1.6
+++ ai12s/ai12-0092-1.txt	2015/01/27 03:25:40	1.7
@@ -6072,28 +6072,28 @@
 Sent: Tuesday, October 14, 2014  4:00 PM
 
 > > So I thought "soft" was the final decision.
-> 
-> No, that was from the original placeholder AI (which was based on 
-> e-mail discussion). When we talked about it in a meeting afterwards 
-> (Pittsburgh - you were there), we decided on "suppressible error", I 
-> think because that suggests the default direction (detected by 
+>
+> No, that was from the original placeholder AI (which was based on
+> e-mail discussion). When we talked about it in a meeting afterwards
+> (Pittsburgh - you were there), we decided on "suppressible error", I
+> think because that suggests the default direction (detected by
 > default). I didn't update the AI afterwards because I thought your were
 > going to do it soon.
 
 OK, I don't remember the Pittsburgh discussion.
 
-> > I read through the entire !appendix, and there were positive notes 
+> > I read through the entire !appendix, and there were positive notes
 > > about "soft".
-> > Many folks like "suppressible", but to me that might imply 
-> > suppressing the diagnostic message, which is exactly the opposite of 
+> > Many folks like "suppressible", but to me that might imply
+> > suppressing the diagnostic message, which is exactly the opposite of
 > > what we're trying to do.
-> 
-> Opposite how? The idea is that these are errors that usually prevent 
-> the partition from running (at least WRT to the Standard). If one 
-> suppresses them, you can run the partition. And surely there would be 
-> no message in the latter case (there's no point in forcing a separate 
-> suppression of the message, as most projects want to be warning clean 
-> as well as error clean, requiring people to write two suppression 
+>
+> Opposite how? The idea is that these are errors that usually prevent
+> the partition from running (at least WRT to the Standard). If one
+> suppresses them, you can run the partition. And surely there would be
+> no message in the latter case (there's no point in forcing a separate
+> suppression of the message, as most projects want to be warning clean
+> as well as error clean, requiring people to write two suppression
 > pragmas and/or options would be silly).
 
 That's not what I intended, and not what the AI says -- it says that violation
@@ -6107,29 +6107,29 @@
 
 Anyway, if your semantics prevails, then "suppressible" makes more sense.
 
-> Obviously, in the case where they are suppressed there has to be 
-> well-defined semantics (which might be erroneous in some cases) so 
+> Obviously, in the case where they are suppressed there has to be
+> well-defined semantics (which might be erroneous in some cases) so
 > whatever happens when they are run makes sense.
 
 Yes (although obviously we'll try hard not to say "erroneous").
 
 >...But I don't see any value to a
 > nagging message after explicit suppression, and surely no value to
-> *requiring* that (that's up to implementers, if they have customers 
+> *requiring* that (that's up to implementers, if they have customers
 >that  find an intermediate mode useful).
 
 Good point.  In other words, as I like to say, the RM doesn't require anybody
 to do anything -- if an implementer doesn't like what it says, they can
 implement nonstandard modes that do something else.
 
-> P.S. Yes, I saw your comments on "error", and I agree that you're 
-> right about that. So probably we're talking "suppressible Legality 
+> P.S. Yes, I saw your comments on "error", and I agree that you're
+> right about that. So probably we're talking "suppressible Legality
 > Rule" or something like that.
 
 OK with me, especially if the semantics really is to suppress the messages.
 
-> P.P.S. And of course I understand Robert's contention that the Ada 
-> standard can't really specify the default behavior; I think it 
+> P.P.S. And of course I understand Robert's contention that the Ada
+> standard can't really specify the default behavior; I think it
 > important that the Standard reflect that intent even if it not really
 > enforceable.
 
@@ -6146,14 +6146,14 @@
 
 ...
 > > > So I thought "soft" was the final decision.
-> > 
-> > No, that was from the original placeholder AI (which was based on 
-> > e-mail discussion). When we talked about it in a meeting afterwards 
-> > (Pittsburgh - you were there), we decided on "suppressible error", I 
-> > think because that suggests the default direction (detected by 
-> > default). I didn't update the AI afterwards because I thought your 
+> >
+> > No, that was from the original placeholder AI (which was based on
+> > e-mail discussion). When we talked about it in a meeting afterwards
+> > (Pittsburgh - you were there), we decided on "suppressible error", I
+> > think because that suggests the default direction (detected by
+> > default). I didn't update the AI afterwards because I thought your
 > > were going to do it soon.
-> 
+>
 > OK, I don't remember the Pittsburgh discussion.
 
 That's why we have the super-secret thing called "meeting minutes". :-)
@@ -6166,5 +6166,861 @@
 cross-linked minutes file, and why I give out HTML links to each person's
 homework.
 
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, January 24, 2015  6:15 AM
+
+[Note: This was split from a thread in AI12-0003-1, as it turned into a
+discussion of this idea again.]
+
+> I agree with this, though I believe soft legality rules would be a
+> feature that would not be appropriate for the corrigenda, ...
+
+I think we should use the "soft legality" concept starting in 1995.  ;-) I'm
+puzzled why it's so controversial, and I don't know why it would be
+inappropriate for the corrigenda.
+
+***************************************************************
+
+From: Brad Moore
+Sent: Saturday, January 24, 2015  7:50 AM
+
+Actually, it appears we've already had them since Ada 83.
+
+See RM 2.8 (13) "The implementation shall give a warning message for an
+unrecognized pragma name."
+
+I'm open to considering soft legality for the corrigenda. I just presumed it
+wasn't a possibility because ai12-0092-1 was not mentioned as being a potential
+corrigenda item in Randy's meeting agenda. Given that we already have soft
+legality rules, maybe the ai12-0092-1 is not even needed.
+
+You could think of this as a "required warning", if it appears as a
+implementation requirement. If it just appears as implementation advice, then it
+is a "recommended warning".
+
+For example, if we wanted the rule I suggested to be a required warning, what
+would stop us from using the following wording?
+
+"The implementation shall give a warning message if a direct_name exists that
+{blah blah blah}"
+
+If we only wanted this to be implementation advice, we could do as Robert
+suggested in the previous email.
+
+In this particular case, I think implementation advice seems like it would be
+more appropriate. The check doesn't affect portability, it just points out to
+the user that his code might be confusing to other readers. That way, a compiler
+vendor that didn't want to implement the check could choose not to.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Saturday, January 24, 2015  8:16 AM
+
+> I think we should use the "soft legality" concept starting in 1995.
+> ;-) I'm puzzled why it's so controversial, and I don't know why it
+> would be inappropriate for the corrigenda.
+
+I strongly agree!
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Saturday, January 24, 2015  8:23 AM
+
+One oddity is that the set of situations we consider for soft legality rules
+(aka required warnings) is that they would be incredibly random in the RM. An
+independent reader might conclude that they are the most critical cases for
+warnings, and nothing could be further from the truth. There are hundreds, even
+thousands of cases in which warnings are valuable, many of them FAR more
+critical than any of the cases we have as candidates for soft warnings in the
+ARG discussions.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Saturday, January 24, 2015  10:26 AM
+
+> You could think of this as a "required warning", if it appears as a
+> implementation requirement. If it just appears as implementation
+> advice, then it is a "recommended warning".
+
+That's what I started with.  But various ARG members didn't like it, because
+it's not strong enough.  They want these things to be considered errors.  The
+whole point is to deal with cases where we want something to be an error (i.e.
+illegal), but to avoid the incompatibility that causes.  Hence "soft legality
+rule".
+
+Randy in particular thinks what we call it is of utmost importance.
+I've no idea why -- "soft error" vs. "required warning" makes no difference to
+me.  I just want ARG to stop introducing all these gratuitous incompatibilities.
+
+Before Tucker jumps in:  I do not claim that ALL incompatibilities are
+gratuitous!
+
+***************************************************************
+
+From: Bob Duff
+Sent: Saturday, January 24, 2015  10:33 AM
+
+> One oddity is that the set of situations we consider for soft legality
+> rules (aka required warnings) is that they would be incredibly random
+> in the RM. An independent reader might conclude that they are the most
+> critical cases for warnings, and nothing could be further from the
+> truth. There are hundreds, even thousands of cases in which warnings
+> are valuable, many of them FAR more critical than any of the cases we
+> have as candidates for soft warnings in the ARG discussions.
+
+Yes.  I'd go further:  some of the warnings produced by some compilers are FAR
+more critical than some existing HARD legality rules. (The case discussed in
+this thread, if we decide to make it a hard legality rule, is one example.  I
+mean, come on, how many bugs are we saving the world from by making sure people
+don't get confused between THE Standard and some user-defined Standard?!
+Warnings about (e.g.) possible uninitialized variables are FAR more important.)
+
+I think my soft-legality proposal included some explanation to help avoid the
+misunderstandings you're worried about.  Make it clear that the purpose is to
+avoid incompatibilities.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Saturday, January 24, 2015  11:13 AM
+
+> Randy in particular thinks what we call it is of utmost importance.
+> I've no idea why -- "soft error" vs. "required warning" makes no
+> difference to me.  I just want ARG to stop introducing all these
+> gratuitous incompatibilities.
+
+LOTS of warnings are serious errors, it is just that the RM does not allow us to
+make them into errors. For instance having an unblocked path from a function
+that raises Program_Error is definitely an error, and the warning we give is
+important. In GNAT we have the capability of turning selected warnings into
+errors.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, January 24, 2015  4:13 PM
+
+> I think we should use the "soft legality" concept starting in 1995.
+> ;-) I'm puzzled why it's so controversial, and I don't know why it
+> would be inappropriate for the corrigenda.
+
+The short answer is that it isn't mature enough for the Corrigendum. It
+*was* eligible to be included.
+
+The longer answer is that we looked at the list of possible AIs to include in
+the Corrigendum during the Portland meeting, and no one asked that we consider
+AI12-0092-1. At this point (since by WG 9 directive, we're working on a timed
+schedule to produce corrigenda, with the intent that we will do one every 3
+years if there is anything at all important enough to publish), we're only
+trying to finish up what's already started and consider the handful of new
+issues raised since. I don't expect that all of those will get in.
+
+One also could consider the strange bifercation between the talk and actions of
+AI12-0092-1 primary author as a significant cause of the lack of maturity for
+the proposal. Nearly a year elapsed from the time the issue was discussed in
+Pittsburgh (Nov 16, 2013) to the time a proposal was actually created -- and the
+author then completely ignored the results of that meeting discussion. (If one
+wants to change something agreed-upon at a meeting, one has to at least posit a
+reason.) Of course, had the author clicked thru the homework links that I
+carefully provide after each meeting, he would have been taken directly to that
+discussion. [The AI numbers in the action item list in the HTML minutes always
+link to the most recent discussion of that AI.] When that was pointed out to
+him, nothing further happened; so the AI state still isn't remotely ready for
+completion.
+
+If the issue was really so important to the author, you'd think that proposals
+would get turned around a lot quicker. I think the rest of us feed off the lack
+of urgency projected by the author.
+
+Note that the "Group of Four" parallel proposals depend on Suppressible Errors,
+as do the compile-time tampering checks that I'll propose for Ada 2020 (they
+need the Global aspect to make any sense, so they have to wait for that to be
+added). So I think the idea will eventually make it into the standard, but I
+have yet to see anything new that requires it.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, January 24, 2015  4:23 PM
+
+...
+> Randy in particular thinks what we call it is of utmost importance.
+> I've no idea why -- "soft error" vs. "required warning" makes no
+> difference to me.
+
+Since the name for this concept that we decided on in Pittsburgh is neither of
+these, it's pretty obvious why you're confused. :-)
+
+...
+> I just want ARG to stop introducing all these gratuitous
+> incompatibilities.
+
+I think there is only one incompatibility since Ada 95 that could possibly be
+called "gratuitous"; every other such incompatiblity has been necessary to make
+the semantics make sense. The alternative of adding additional erroneous cases
+(or unspecified behavior, in some cases) - the only real alternative most of the
+time - is at least as bad.
+
+One of the things we tasked you to do was to show us with concrete examples of
+where Suppressible Errors could have been used. So far as I know, there has only
+been one decent example, and not everyone agreed with that. We probably need
+more to get the idea to fly.
+
+Anyway, why did you hijack this thread with this off-topic discussion???
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, January 24, 2015  4:34 PM
+
+...
+> I think my soft-legality proposal included some explanation to help
+> avoid the misunderstandings you're worried about.
+> Make it clear that the purpose is to avoid incompatibilities.
+
+The uses that will likely get it into the Standard have nothing to do with
+incompatibilities. (The parallel proposals, in particular.) They have to do
+directly with the idea of suppressing a safety-net check when the programmer is
+sure that all is OK. In particular, if we have compile-time tampering checks,
+making those suppressible would allow using subprograms that don't have Global
+aspects. But of course if you do, and someone tampers, your program is
+erroneous. That allows the programmer to make the choice between erroneous
+execution and static checking that might be a pain.
+
+But I don't see any case where we could introduce static tampering checks in the
+existing containers. That's because viritually all existing code would fail such
+a check (since no existing subprograms have Global aspects, any existing
+subprogram call would fail the static check), and making everyone suppress the
+checks all the time would completely defeat the purpose of having them in the
+first place. So I think we could only use this in new kinds of containers
+[especially a "parallel" container; the existing containers can't define proper
+Global aspects on reading which would be a problem using them in parallel
+loops]. (Similarly, the parallel constructs are something new; there's no
+compatibility concern there, but there is a concern that the checks could be too
+fierce in some circumstances. Thus the desire to give programmers an out.)
+
+***************************************************************
+
+From: Bob Duff
+Sent: Saturday, January 24, 2015  5:12 PM
+
+> One also could consider the strange bifercation between the talk and
+> actions of AI12-0092-1 primary author as a significant cause of the
+> lack of maturity for the proposal.
+
+The author is just too discouraged by the lack of support for the idea to put
+much energy into it.  And busy doing work that actually affects real-live Ada
+users.
+
+>... Nearly a year elapsed from the time the issue was  discussed in
+>Pittsburgh (Nov 16, 2013) to the time a proposal was actually  created
+>-- and the author then completely ignored the results of that  meeting
+>discussion.
+
+Not on purpose.  IIRC, I used the wrong version of minutes, or something like
+that.
+
+> Note that the "Group of Four" parallel proposals depend on
+> Suppressible Errors,
+
+Is that the term decided upon in Pittsburgh?  I'd have to do more study to be
+sure, but I don't see how that fits into the existing RM, where "error" is used
+much more broadly than "violation of legality rule". It includes raising of
+predefined exceptions for example.  See 1.1.5. I think perhaps people are
+confusing the RM notion of "error" with the notion of "error" in GNAT and other
+compilers (where "error" does indeed mean "violation of a legality rule").
+
+I was hoping to avoid a total rewrite of 1.1.5 (etc) just to get such a simple
+idea into the RM.
+
+> ...Anyway, why did you hijack this thread with this off-topic
+> discussion???
+
+I didn't think I was "hijacking" by pointing out that this specific issue is an
+example of a more general idea.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, January 24, 2015  5:35 PM
+
+...
+> > Note that the "Group of Four" parallel proposals depend on
+> > Suppressible Errors,
+>
+> Is that the term decided upon in Pittsburgh?  I'd have to do more
+> study to be sure, but I don't see how that fits into the existing RM,
+> where "error" is used much more broadly than "violation of legality rule".
+> It includes raising of predefined exceptions for example.  See 1.1.5.
+> I think perhaps people are confusing the RM notion of "error"
+> with the notion of "error" in GNAT and other compilers (where "error"
+> does indeed mean "violation of a legality rule").
+
+I think you pointed that out in an e-mail exchange that we had back in October.
+I think we (you and I) decided that "Suppressible Legality Rule" (and possibly
+others starting with "Suppressible") would be the actual term.
+
+I was rather hoping that you'd have written that up by now.
+
+> I was hoping to avoid a total rewrite of 1.1.5 (etc) just to get such
+> a simple idea into the RM.
+
+Understood.
+
+> > ...Anyway, why did you hijack this thread with this off-topic
+> > discussion???
+>
+> I didn't think I was "hijacking" by pointing out that this specific
+> issue is an example of a more general idea.
+
+I guess I was frustrated by your bringing up soft errors here, because there is
+no compatibility issue (this is a new feature that we're talking about), and the
+whole thing is IMHO exceedingly unimportant. If we don't have the will for a
+Legality Rule, I'd hope that then we'd just use an AARM note to point out that
+an implementation might want a warning. Leave it up to the implementer to decide
+what to warn on.
+
+Sorry about taking out my frustration over having to spend a lot of time on this
+check (which should either be bog-simple or non-existent) on you.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Saturday, January 24, 2015  5:38 PM
+
+> I think there is only one incompatibility since Ada 95 that could
+> possibly be called "gratuitous"; every other such incompatiblity has
+> been necessary to make the semantics make sense. The alternative of
+> adding additional erroneous cases (or unspecified behavior, in some
+> cases) - the only real alternative most of the time - is at least as bad.
+
+ALL incompatibilities are a bad idea. The predilection of language designers to
+genuinely believe that they have to introduce incompatibilities to "make the
+semantics make sense" never ceases to amaze me.
+
+Ada 2005 was in my mind pretty much a failure, in that we implemented it, but
+few users made the transition, and there is no question that the
+incompatibilities in return of limited types acted as a major barrier.
+
+The barrier is still there for the transition to Ada 2012 (and continues to
+cause major problems). but the contracts of Ada 2012 are worth while enough for
+people to fight through this issue.
+
+Now if the change had come from significant users saying that they had a real
+problem in practice with Ada 95 semantics, that would be one thing, but that was
+not the impetus as far as I know. Instead it was language designers putting
+elegant "sensible" semantics ahead of pracctical considerations.
+
+BTW, we often run into errors that cause people trouble, and what we do is to
+have a debug switch that converts these into warnings :-)
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Sunday, January 25, 2015  2:20 PM
+
+> ...  and there is no question that
+> the incompatibilities in return of limited types acted as a major
+> barrier. ...
+
+I think there is a tad bit of hyperbole here, but I admit that this particular
+incompatibility is painful.  But there was clearly a cost/benefit tradeoff to
+make, and I believe the ARG made the right one, since I believe the advantage in
+being able to construct new limited-type objects in a function exceeds the pain
+associated with not being able to return existing limited-type objects by
+reference.  There are several ways to work around the feature that was lost, but
+the new capability is truly a gain in functionality.
+
+I think every language reviser has to make these trade-offs, and clearly not
+everyone makes the trade-off the same way, but it was not merely a matter of
+"elegance," it was a matter of gaining important functionality.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Sunday, January 25, 2015  4:07 PM
+
+I certainly don't consider this case of incompatibility to be "gratuitous".
+
+OTOH, one could argue that PART of the change was gratuitous, or at least
+unnecessary.  In particular, b-i-p was supposed to replace return-by-reference,
+so r-by-r had to be made (hard) illegal.  But we also made the return-by-copy
+cases illegal, and we didn't have to do that.  See example below, which was
+legal in 83 and 95, but illegal in 2005 and 2012.  We could have said it has the
+same semantics as in Ada 83, namely return-by-copy.
+
+And we could have made the rule a Suppressable Legality Rule in that case, if we
+had thought of it.
+
+That would have reduced the incompatible cases by a factor of 3, if I remember
+my experiments correctly.  Use of r-by-r was fairly rare, which (with 2020
+hindsight) is not surprising.
+
+It would require breaking privacy, which is a Bad Thing, but I think
+incompatibilies are a Worse Thing.  So what if making the full type of T in my
+example makes Q illegal?  Whatever maintenance headaches would be caused by that
+are actually caused by the incompatibility, even in the NON-limited (full type)
+case.
+
+In effect ARG said, "Because you MIGHT have to change your code in the future
+during maintenance, we're going to FORCE you to change it now." User response in
+some cases was, "Then forget Ada, I'll keep using the non-ISO-standard thing
+called Ada 95."  Never forget that conforming to standards is optional!
+
+package P is
+   type T is limited private;
+   procedure Init (Obj : out T; X : Integer); private
+   type T is record
+      X : Integer;
+   end record;
+end P;
+
+package body P is
+   procedure Init (Obj : out T; X : Integer) is
+   begin
+      Obj.X := X;
+   end Init;
+end P;
+
+with P;
+package Q is
+   function FF (X : Integer) return P.T; end Q;
+
+package body Q is
+   function FF (X : Integer) return P.T is
+      Result : P.T;
+   begin
+      P.Init (Result, 123);
+      return Result; -- Illegal in Ada 2005 and 2012!
+   end FF;
+end Q;
+
 ***************************************************************
- 
\ No newline at end of file
+
+From: Bob Duff
+Sent: Sunday, January 25, 2015  4:27 PM
+
+> ALL incompatibilities are a bad idea. The predilection of language
+> designers to genuinely believe that they have to introduce
+> incompatibilities to "make the semantics make sense" never ceases to
+> amaze me.
+
+Have you followed the development of Python?  Apparently the change from Python
+2.8 to Python 3.0 (or whatever) was hugely incompatible, to the point where the
+simplest "Hello, world" program needs to be rewritten. And apparently many
+Python users are still stuck in 2.x world.
+
+It seems downright irresponsible to me.  ARG would NEVER do that sort of thing.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Sunday, January 25, 2015  4:58 PM
+
+> I think you pointed that out in an e-mail exchange that we had back in
+> October. I think we (you and I) decided that "Suppressible Legality Rule"
+> (and possibly others starting with "Suppressible") would be the actual term.
+
+OK.
+
+> I was rather hoping that you'd have written that up by now.
+
+Understood.
+
+> I guess I was frustrated by your bringing up soft errors here, because
+> there is no compatibility issue...
+
+Then I didn't make myself clear.  I was saying that we could have a rule that
+forbids declaring anything anywhere with the name Standard. I think that's a
+good idea anyway, because then you're guaranteed to have a full expanded name
+for every package.
+
+Objection!  That's a gratuitous incompatibility!
+
+Answer:  Suppressible Legality Rule.
+
+> and the whole thing is IMHO exceedingly unimportant.
+
+I certainly agree with that.
+
+>... If we don't have the
+> will for a Legality Rule, I'd hope that then we'd just use an AARM
+>note to  point out that an implementation might want a warning. Leave
+>it up to the  implementer to decide what to warn on.
+
+That's fine, too.
+
+> Sorry about taking out my frustration over having to spend a lot of
+> time on this check (which should either be bog-simple or non-existent) on you.
+
+Yes, "non-existent" probably.  I understand your frustration, but it's in the
+nature of things -- people always want to discuss the simple things.  Look up
+the term "bikeshedding", if you're not already familiar with the term.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Sunday, January 25, 2015  9:45 PM
+
+> I think there is a tad bit of hyperbole here, but I admit that this
+> particular incompatibility is painful.  But there was clearly a
+> cost/benefit tradeoff to make, and I believe the ARG made the right
+> one, since I believe the advantage in being able to construct new
+> limited-type objects in a function exceeds the pain associated with
+> not being able to return existing limited-type objects by reference.
+> There are several ways to work around the feature that was lost, but the new capability is truly a gain in functionality.
+
+Well I don't think it is hyperbole, several of our major customers tried moving
+to Ada 2005, ran into this incompatibility, which is not so easy to fix in big
+legacy codes, and gave up on Ada 2005. Almost none of our customers migrated to
+Ada 2005 (this I surmise from code that people have sent us).
+
+As I said, if we had had important customers complain about not being able to
+"construct new limited-type objects in a function" then that would have been
+significant, but I don't remember a single suggestion receieved along those
+lines (and our customers are not shy about complaining about missing features
+and suggesting enhancements).
+
+> I think every language reviser has to make these trade-offs, and
+> clearly not everyone makes the trade-off the same way, but it was not
+> merely a matter of "elegance," it was a matter of gaining important functionality.
+
+I think more effort should have been made to do this in an upwards compatible
+manner (at worst with a pragma controlling things, but I bet we could have done
+better).
+
+And I still think that when I hear "There are several ways to work around the
+feature that was lost", it implies a lack of awareness of just how difficult it
+it is to apply such work arounds to millions of lines of legacy code.
+
+Anyway, water under the bridge, but I do think we have to tread carefully when
+it comes to ANY incompatibility, even if it seems to us that there are easy work
+arounds.
+
+I was quite struck by the Birmingham presentation one company made on moving
+from Ada 95 that the biggest problem they had encountered was INTERFACE being a
+new keyword. Now it might seem trivial to just change the name, but the problem
+was that they had a codified use of that identifier in modules shared across
+several development projects on different schedules, and forcing the necessary
+coordination was very painful for them.
+
+I for sure agree that making it illegal to redeclare Standard would be a
+gratuitous incompatibility. For fun I will try  our test suite with that change
+:-)
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Sunday, January 25, 2015  9:50 PM
+
+> In effect ARG said, "Because you MIGHT have to change your code in the
+> future during maintenance, we're going to FORCE you to change it now."
+> User response in some cases was, "Then forget Ada, I'll keep using the
+> non-ISO-standard thing called Ada 95."  Never forget that conforming
+> to standards is optional!
+
+And imagine reporting two different things to your boss responding to his
+suggestion to examine a move to Ada 2005.
+
+a) Very little (or no) effort in the move
+
+b) We ran into quite a difficult case, with no automatic work around. We don't
+know how much work it would be to do these work arounds by hand, shall we
+investigate.
+
+Now imagine the bosses reaction to a) and b)
+
+Part of the trouble with Ada 2005 was that it had nothing sufficiently
+convincing on the positive side for many users to justify the difficulty in
+switching.
+
+Now for Ada 2012, the contract stuff has really caught the imagination of a LOT
+of users, and we see lots of our users experimenting (*) with contracts.
+
+(*) and furiously reporting bugs :-) :-)
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Sunday, January 25, 2015  9:51 PM
+
+> Have you followed the development of Python?  Apparently the change
+> from Python 2.8 to Python 3.0 (or whatever) was hugely incompatible,
+> to the point where the simplest "Hello, world" program needs to be rewritten.
+> And apparently many Python users are still stuck in 2.x world.
+>
+> It seems downright irresponsible to me.  ARG would NEVER do that sort
+> of thing.
+
+I agree the Python change was FAR worse than anything that the ARG would
+countenance. Of course in the Python world there are fewer cases of giant legacy
+programs with millions of lines of code (actually the number of such cases might
+well be zero).
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 26, 2015  3:54 PM
+
+...
+> > I guess I was frustrated by your bringing up soft errors here,
+> > because there is no compatibility issue...
+>
+> Then I didn't make myself clear.  I was saying that we could have a
+> rule that forbids declaring anything anywhere with the name Standard.
+> I think that's a good idea anyway, because then you're guaranteed to
+> have a full expanded name for every package.
+>
+> Objection!  That's a gratuitous incompatibility!
+>
+> Answer:  Suppressible Legality Rule.
+
+*That* makes sense, but I don't think everyone understood it that way.
+
+And I don't think it would fly, for similar reasons that unreserved keywords
+don't fly. (Not that I understand that, either.)
+
+***************************************************************
+
+From: Bob Duff
+Sent: Monday, January 26, 2015  5:13 PM
+
+> *That* makes sense, but I don't think everyone understood it that way.
+
+Yes, at least one other person misunderstood me, too, so apparently I wasn't
+clear at first.  Sorry about that.
+
+> And I don't think it would fly, for similar reasons that unreserved
+> keywords don't fly.
+
+Well, I was hoping that "Suppressible Legality Rules" would solve the
+(political) keyword problem.  As in, "interface" shall not be used as an
+identifier.  But, oh by the way, that's suppressible.
+
+> ...(Not that I understand that, either.)
+
+I understand why people don't like unreserved keywords.  What I don't understand
+is why they think "don't like it" should trump compatibility concerns.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 26, 2015  5:28 PM
+
+Indeed!
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Monday, January 26, 2015  5:41 PM
+
+We lost this one several times at the WG-9 level.  The EU has more votes than
+the US! ;-)
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 26, 2015  6:08 PM
+
+Ironic since in my experience, these incompatibilities hit European users more
+severely. Europeans are much more experimental in moving to new versions of Ada,
+US users tend to be much more conservative. We still have lots of users who
+stick with Ada 83.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 26, 2015  4:07 PM
+
+...
+> That would have reduced the incompatible cases by a factor of 3, if I
+> remember my experiments correctly.  Use of r-by-r was fairly rare,
+> which (with 2020 hindsight) is not surprising.
+>
+> It would require breaking privacy, which is a Bad Thing, but I think
+> incompatibilies are a Worse Thing.  So what if making the full type of
+> T in my example makes Q illegal?  Whatever maintenance headaches would
+> be caused by that are actually caused by the incompatibility, even in
+> the NON-limited (full
+> type) case.
+
+I'm pretty sure something like that was considered, but it didn't fly
+politically.
+
+Why not? In large part because breaking privacy also had the effect of breaking
+the incremental compilation model of the Rational compiler. And remember who the
+chair of the ARG was during this period...
+
+We also considered making constructors something different than functions. I
+still think that would have been the way to go, but others thought that it would
+have replaced one wart with two warts. In particular, a lot of the functionality
+of a function and of a constructor overlap. So users would have been faced with
+the question of which one to use when implementing something. The choice would
+not always be obvious given the difference in usage (a constructor could only
+have been used in initialization contexts -- not assignments, while a function
+could be used everywhere). Most thought it was too confusing.
+
+> package body Q is
+>   function FF (X : Integer) return P.T is
+>      Result : P.T;
+>   begin
+>      P.Init (Result, 123);
+>      return Result; -- Illegal in Ada 2005 and 2012!
+
+I think this is illegal in Ada 95, too. This return fails an accessibility
+check.
+
+>   end FF;
+>end Q;
+
+You have return a global in this case:
+
+package body Q is
+   Result : P.T;
+
+   function FF (X : Integer) return P.T is
+   begin
+      P.Init (Result, 123);
+      return Result; -- Illegal in Ada 2005 and 2012, OK in Ada 95!
+   end FF;
+end Q;
+
+And the use of a global in cases like this makes it dubious (non-task-safe at a
+minimum) anyway. One of the reasons we decided to swallow the incompatibility.
+Of course, it might not be as dubious if the global exists for some other reason
+and/or is protected with a lock (and of course if no one every uses a task,
+plenty common in Ada code). Obviously, there's a lot more of it than we thought.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Monday, January 26, 2015  5:34 PM
+
+> > package body Q is
+> >   function FF (X : Integer) return P.T is
+> >      Result : P.T;
+> >   begin
+> >      P.Init (Result, 123);
+> >      return Result; -- Illegal in Ada 2005 and 2012!
+>
+> I think this is illegal in Ada 95, too. This return fails an
+> accessibility check.
+
+No, it is legal, and does not fail any checks.  It returns Result BY COPY.
+
+I think you missed the fact that, although P.T is limited, its full type is
+nonlimited, so none of the return-by-reference stuff in Ada 95 applies (and
+therefore, none of the build-in-place stuff in Ada 2005 needs to apply, if one
+is willing to break privacy).
+
+This is plain vanilla Ada 83 code, no return-by-reference involved.
+
+> >   end FF;
+> >end Q;
+>
+> You have return a global in this case:
+>
+> package body Q is
+>    Result : P.T;
+>
+>    function FF (X : Integer) return P.T is
+>    begin
+>       P.Init (Result, 123);
+>       return Result; -- Illegal in Ada 2005 and 2012, OK in Ada 95!
+>    end FF;
+> end Q;
+>
+> And the use of a global in cases like this makes it dubious
+> (non-task-safe at a minimum) anyway. One of the reasons we decided to
+> swallow the incompatibility. Of course, it might not be as dubious if
+> the global exists for some other reason and/or is protected with a
+> lock (and of course if no one every uses a task, plenty common in Ada
+> code). Obviously, there's a lot more of it than we thought.
+
+No no, you're thinking return-by-reference here.
+
+My point was that the incompatibilies were:
+
+    1/3 return-by-ref that really needs to be modified in the presence
+    of b-i-p.
+
+    2/3 return-by-copy of limited types, which we (gratitously, IMHO)
+    made illegal.  My example was illustrating this more-common case.
+
+The 1/3 and 2/3 are from memory of my experiments -- I could be off.
+
+
+P.S. If I become "e-mail dark" in the next day or two, it means the blizzard
+dumped a huge amount of heavy wet snow on a tree branch, and the strong winds
+blew down said branch, and it knocked down a power line that supplies
+electricity to this computer.  You may then assume I'm reading a paperback novel
+by candle light.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 26, 2015  8:48 PM
+
+> > > package body Q is
+> > >   function FF (X : Integer) return P.T is
+> > >      Result : P.T;
+> > >   begin
+> > >      P.Init (Result, 123);
+> > >      return Result; -- Illegal in Ada 2005 and 2012!
+> >
+> > I think this is illegal in Ada 95, too. This return fails an
+> > accessibility check.
+>
+> No, it is legal, and does not fail any checks.  It returns Result BY
+> COPY.
+>
+> I think you missed the fact that, although P.T is limited, its full
+> type is nonlimited, so none of the return-by-reference stuff in Ada 95
+> applies (and therefore, none of the build-in-place stuff in Ada 2005
+> needs to apply, if one is willing to break privacy).
+
+I made the mistake of thinking that Ada 95 didn't have any privacy-breaking
+Legality Rules (because I didn't remember any).
+
+But clearly this case is privacy-breaking (I just went and looked it up with old
+wording, it's crystal-clear that it breaks privacy). So we could have retained
+that privacy-breaking to reduce the incompatibility. Not sure why we didn't
+(perhaps Pascal was looking forward to getting rid of a hack in their compiler?
+:-).
+
+...
+> My point was that the incompatibilies were:
+>
+>     1/3 return-by-ref that really needs to be modified in the presence
+>     of b-i-p.
+>
+>     2/3 return-by-copy of limited types, which we (gratitously, IMHO)
+>     made illegal.  My example was illustrating this more-common case.
+>
+> The 1/3 and 2/3 are from memory of my experiments -- I could be off.
+
+Right. If the Ada 95 rule was privacy-breaking (and it was), we could have
+retained that part of it just to reduce the incompatibility; no one could have
+truly complained because the effect would have been the same as in Ada 95.
+
+But either we didn't think of it, were seduced by cleaning up a mess in the
+language without noting possible impacts, or ???. Anyway, way too late now (and
+at least we ended up with one less wart).
+
+> P.S. If I become "e-mail dark" in the next day or two, it means the
+> blizzard dumped a huge amount of heavy wet snow on a tree branch, and
+> the strong winds blew down said branch, and it knocked down a power
+> line that supplies electricity to this computer.  You may then assume
+> I'm reading a paperback novel by candle light.
+
+Could be more fun than reading the ARG list. ;-) We just got an inch of snow
+yesterday and are supposed to get another inch tonight. And temps just below
+freezing (no deep-freeze, knock wood). I think we're getting off easy.
+
+***************************************************************
+

Questions? Ask the ACAA Technical Agent