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

--- ai12s/ai12-0229-1.txt	2017/04/22 03:34:43	1.3
+++ ai12s/ai12-0229-1.txt	2019/02/07 06:31:30	1.4
@@ -933,3 +933,120 @@
 Better than appalling ;-)
 
 ****************************************************************
+
+From: Richard Wai
+Sent: Friday, January 11, 2019  10:42 AM
+
+Sorry for any trouble this causes to dig-up, but looking through the voting 
+list, this AI caught my eye.
+
+From a user perspective, I feel like this proposal is a bit risky. A really 
+important strength of Ada is its relative orthogonality, especially given 
+its size. This orthogonality is especially important when training newcomers 
+to Ada, and getting them effective in as short of a time as possible. The 
+type system in Ada is already unique enough to throw-off most newcomers to
+the language, and I think we should be very careful about introducing 
+additional special cases which are easy to misunderstand. I think this AI is 
+a great example of something which is both somewhat un-orthogonal, and also 
+easily misunderstood.
+
+A common issue I've seen with newbies is the classic use type and use all 
+type semantics. Avoiding full use clauses is obviously desirable, but we 
+also know that use type does not bring the name of the type into direct 
+visibility where it is used. So use type P.X means we still need to use
+My_X: P.X. This already is a bit awkward, since the full use does not 
+behave this way.
+
+Naturally for many, they then wonder, "can I do type X renames P.X?". Of 
+course the answer has been "no, use a subtype" thus far. If we implement 
+this AI, the answer doesn't change to "Yes", it changes to "well kinda, 
+not really though, you should still use subtypes, except if ......". I'm 
+especially unsettled by the idea of "automating renames" with special 
+invisible renames which do not act the same as actual renames (vis-à-vis 
+dispatching operations) - this is really ugly and orthogonal.
+
+This time, however, I have a proposal that does not involve throwing out 
+the proverbial baby with the bathwater!
+
+How about make this an aspect instead?
+
+generic
+package GP is
+	type A is Integer;
+	type B is Integer;
+	function F(X : A, Y : B) return B;
+	An_Excep: exception;
+end GP;
+
+with GP;
+package Enclosing is
+	package Inst is new GP
+		with Import_Types => A, B;
+end Enclosing;
+
+And then all the actual semantics will be the same, except perhaps we can say 
+it a bit more specific to the aspect rather than talking about "automatic 
+renames that follow different rules than actual renames".
+
+I think using an aspect is ideal for these kind of cases stuck somewhere 
+between special and common, but not especially common.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 11, 2019  5:00 PM
+
+Thanks for the comments, Richard.
+
+This particular proposal isn't even half-baked, I'd pretty much call it raw 
+dough. As such, and given our current deadlines, there's approximately no 
+chance that it will end up in Ada 2020. So we will have a long time to discuss 
+this one.
+
+As noted in the old e-mail thread, we have repeatedly tried to solve this 
+problem unsuccessfully. There is a high probability that this idea won't work, 
+either. And in particular, we had the "integrated package" proposal.
+Your proposal is rather close to that, although it does include some of the 
+features of the proposal given here. I would guess that the primary difference 
+is whether or not there is a use for type renaming away from the motivating 
+case of generic instantiation. If there is, then of course a solution tied to 
+instances is less appealing. ("Integrated packages" worked with any nested 
+package, not just an instance.)
+
+I don't see any difference in description, however. Every Ada entity has a 
+well-defined place where they are declared, and we certainly would not want 
+this feature to change that. It's much, much easier to describe this (however 
+it is written) as equivalent to a sequence of renamings than to reproduce all 
+of the rules for renamings for this new construct (and inevitably miss some).
+
+In any case, I'm somewhat confused about your concern about the difference in 
+renaming semantics. That difference is only for a single property 
+(dispatching), where is it well known that the Ada semantics of renaming is 
+badly broken. All other properties work identically. (It's badly broken, as 
+when faced with a choice between two options for an inconsistency (fully 
+consistent being impossible), Ada 95 picked the one that is very unlikely to 
+appear - requiring use of nested packages to declare non-primitive operations 
+in the same package, as opposed to a relatively common case as in these 
+examples.) In particular, using existing Ada renamings by hand to have this 
+effect would not work if dispatching is needed (using conventional call 
+notation). This would be a serious problem for any OOP designs. End users 
+would never know the difference, because their programs would work as they 
+expect (unlike what happens with existing renames).
+
+If your concern is shared by many others, I would strongly suggest changing 
+all renames to work as described in this proposal, as that would be 
+incompatible only in unusual programs, and it would enable useful OOP 
+renamings, which we don't have currently. Rather than throwing out this idea 
+completely. That's not been proposed mainly because it's not clear precisely 
+how much incompatibility would be involved (I don't think it is much, but I 
+haven't tried hard to think about it).
+
+I certainly can understand discomfort with the entire idea of renamings 
+(aliasing is almost always a problem), but I don't quite understand why 
+someone would object to doing renames the way they ought to work.
+
+Anyway, by the time we do consider this, you'll have been here a while and 
+you'll be a lot more comfortable making comments. So I wouldn't worry much 
+about this one.
+
+****************************************************************