CVS difference for ai05s/ai05-0277-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0277-1.txt

--- ai05s/ai05-0277-1.txt	2011/12/29 08:48:17	1.1
+++ ai05s/ai05-0277-1.txt	2012/01/05 06:19:33	1.2
@@ -187,3 +187,73 @@
 "Incompatibilities with Ada2005" list, the better!
 
 ****************************************************************
+
+From: Bob Duff
+Sent: Saturday, November 12, 2011  6:20 PM
+
+I agree, except I think it IS pretty high priority.  This incompatibility is
+completely unnecessary.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, November 12, 2011  6:32 PM
+
+I agree with Bob on both points. Incompatibilities are a real problem.
+They have the significant effect of seriously impeding adoption. If people
+compile their existing code and get a bunch of mysterious errors they do not
+understand, then they just put off making the transition.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, November 12, 2011  6:36 PM
+
+We just voted to go back to *requiring* "aliased" if you want to use 'Access,
+but adding a legality rule that you can only use "aliased" on an extended return
+object declaration if the type of the object is immutably limited.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, November 12, 2011  7:00 PM
+
+Good.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December 30, 2011  1:10 AM
+
+I need to point out that this is still (technically) incompatible, and thus does
+nothing to reduce the number of entries in the "Incompatibilities with Ada 2005"
+list. (And it wouldn't anyway, because there is a second incompatible item in
+that subclause, and there is only one index entry per subclause.)
+
+Specifically, if an Ada 2005 user had written "aliased" on an object that is not
+immutably limited, it is now illegal. This is a "good" incompatibility, as we
+don't really know how that could be implemented sanely. (It could allow an
+object that is built-in-place but is not declared aliased to have its 'Access
+taken, which is trouble as the object might not have the representation of an
+aliased object. There are more fun examples in the original AI - AI05-0053-1.)
+
+It's also true that "aliased" on extended return objects was formally a no-op in
+Ada 2005, as there was no wording making such an object aliased -- so a
+"correct" compiler would never have allowed anything useful anyway. (However, I
+suspect most Ada 2005 implementations followed the Dewar rule here, thus we have
+to worry about the incompatibility.)
+
+No big deal, but I didn't want any misconceptions out there.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Friday, December 30, 2011  9:52 AM
+
+My comment was not intended to shorten the list of incompatibilities in the RM, but
+just to minimize the aggravation of users in the face of this change. Most of the
+examples I have seen apply the qualifier to immutably limited objects, so there will
+be fewer unwelcome surprises. A very pragmatic consideration, which unfortunately
+does not simplify in any way the job of the editor....
+
+****************************************************************

Questions? Ask the ACAA Technical Agent