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

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0123-1.txt

--- ai05s/ai05-0123-1.txt	2008/12/05 05:27:44	1.4
+++ ai05s/ai05-0123-1.txt	2009/02/05 05:28:07	1.5
@@ -1621,10 +1621,102 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Friday, December 5, 2008  12:00 AM
+
+I agree this is a simpler and better solution.  Namely, all untagged private types,
+whether formal private or package private, are treated as though they are untagged
+record types, so no "late" or "private" primitive definition of "=" may be given
+for any descendant of one.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Friday, December 5, 2008  12:00 AM
+
+> Humm; generally we want regular private types and formal private types to
+> work the same way. And even though Mr. Private is (mostly) retired, I doubt
+> that we want to break privacy to make such a check. 
+
+Retired but watchful.  I think you are perfectly right, you need to reject the
+private "=" in your example.  Not only is this AI getting more and more hairy
+(hairier and hairier?), but it looks less and less useful with all these weird
+restrictions that are going to puzzle users.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Friday, December 5, 2008  12:11 AM
+
+At this point I'd start to worry about the impact of the incompatibilities.
+
+****************************************************************
+
 From: Randy Brukardt
 Sent: Thursday, December 4, 2008  11:26 PM
 
 Why do I feel like this AI is like a sinkhole? If you get too close to the
 edge, another chunk breaks off and falls into the ever-widening pit... ;-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, December 5, 2008  1:58 PM
+
+So maybe we should back off from this particular pit.
+We've lived with this language bug for many years now...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, December 5, 2008  2:07 PM
+
+Nah.  Let's get it right, and then make an informed decision.  Writing an AI is
+like making sausage. The final result may be great, but you don't want to look
+too closely at the process of getting there.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, December 5, 2008  4:23 PM
+
+Well, let's not fall into the trap of "we've done a lot of work on X, so we have
+to include X in the final thing, or all that work will be wasted".
+It's easy to do that, subconciously.
+
+I think that's what happened with anonymous access types.
+It would have been better to leave them out, IMHO, since they don't solve the
+problems they were intended to solve.
+Which reminds me: I need to respond to the T'Ref thread.
+I'm afraid I'm rather negative on the idea of "fixing"
+anon acc types.
+
+Also, in a world where only one implementer has implemented Ada 2005, and only
+just barely, I'm not inclined to spend a lot of energy on Sausage 2015 -- I think
+it should be a modest update, compared to Adas 95 and 2005, which were both quite
+huge.  It would be good for Ada, and good for the world, to have more than one
+up-to-date Ada implementation.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December 5, 2008  8:24 PM
+
+> At this point I'd start to worry about the impact of the incompatibilities.
+
+I do, too, but you have to keep in mind that these incompatibilities can only
+happen when you derive from an untagged type AND provide a new "=" operator for
+the derivation. The next time I do that will be the first (and I've been
+programming in Ada for 28 years!).
+
+Once Steve writes up the exact rules, we can try to find out if any
+incompatibility appears in practice (much as was done in the first place). After
+all, this entire notion is incompatible (inconsistent, in fact, with no
+compile-time detection available). But it still seems like a good idea.
+
+It also should be noted that none of these rules seem absolutely necessary;
+we simply could revert to no composition in such cases. But (presuming that
+we don't find significant real incompatibilities) that seems to just be adding
+a new source of bugs.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent