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

--- ai12s/ai12-0229-1.txt	2017/04/21 05:43:53	1.2
+++ ai12s/ai12-0229-1.txt	2017/04/22 03:34:43	1.3
@@ -1,4 +1,4 @@
-!standard 8.5.6(0)                                    17-04-19  AI12-0229-1/01
+!standard 8.5.6(0)                                    17-04-21  AI12-0229-1/02
 !class Amendment 17-04-19
 !status work item 17-04-19
 !status received 17-03-24
@@ -49,9 +49,9 @@
     type defining_identifier {, defining_identifier} renames type_name {, type_name}
        [aspect_specification];
 
-[Note: This is closely related to the proposed syntax in AI12-0226-1; the main
+[Note: This is closely related to the proposed syntax in AI12-0223-1; the main
 difference is that this feature is believed to work semantically, and the
-AI12-0226-1 is not believed to work.]
+AI12-0223-1 proposal is not believed to work.]
 
 Static Semantics
 
@@ -156,37 +156,52 @@
 all cases, all that is needed is to prefix the usage with the appropriate
 package name.
 
-A package content renaming facility would be different, however. The primary purpose of such a facility is to provide a more
-convinient view for CLIENTS of the package containing the package contents renaming construct. As such, if unrelated program
-maintenance made the package contents renaming facility illegal, the package owner would be faced with two unpleasant choices:
-either remove the package contents renaming construct (breaking all clients that depend upon it), or remove/rename the
-conflicting declaration (breaking all clients that used that declaration). This is a ripple-like effect, as now many (and often all)
-of the clients also need changing.
-
-This problem is severe enough that it would make changing the language-defined packages very difficult, as any significant change
- - especially to non-overloadable entities - would be significantly incompatible. A similar problem would apply to third-party
-libraries like GTKAda.
-
-Additionally, this facility is likely to be used frequently on containers packages. But an instance of any Ada language-defined
-container would always conflict with another if both used a package contents renaming construct -- they both would contain the
-non-overloadable constant No_Cursor, for one example.
-
-Since type renaming only renames subprograms that are related to the renamed type(s), the scope of conflicts is much more restricted.
-(In the motivating case of types declared in a generic instantiation, there cannot be any conflicting operations declared before
-the instance.) Moreover, having two subprograms with the same name and profile, but different purposes, is a problem regardless of
-how the subprograms are called. One of the subprograms ought to be changed in such a case anyway. In addition, if the routines
-actually have the same function (as might happen if a previously separate routine is added to a generic unit), the error will point
-out the duplicate declaration (and removing it would not affect clients). Thus, an error in a type renaming probably really reflects
-an error (either of design or duplication), and thus will not be common.
-
-Thus we judge that the maintenance hazards from the proposed type renaming construct are low enough to live with, while the hazards from
-a package contents renaming are unacceptable.
-
-[Aside: This analysis suggests that no one should use constants of an ADT in a package specification, as such constants are not
-overloadable. Instead, a parameterless function should be used; such a function would be made visible by "use all type" and
-renamed by type renaming, while neither happens for a constant. In a perfect world, objects would overload like functions (the fact that
-a constant can be replaced by a function shows a model for doing so), but this seems too risky for Ada at this time. So one should avoid
-constants if the equivalent function would be primitive.
+A package content renaming facility would be different, however. The primary
+purpose of such a facility is to provide a more convinient view for CLIENTS of
+the package containing the package contents renaming construct. As such, if
+unrelated program maintenance made the package contents renaming facility
+illegal, the package owner would be faced with two unpleasant choices: either
+remove the package contents renaming construct (breaking all clients that
+depend upon it), or remove/rename the conflicting declaration (breaking all
+clients that used that declaration). This is a ripple-like effect, as now
+many (and often all) of the clients also need changing.
+
+This problem is severe enough that it would make changing the language-defined
+packages very difficult, as any significant change - especially to
+non-overloadable entities - would be significantly incompatible. A similar
+problem would apply to third-party libraries like GTKAda.
+
+Additionally, this facility is likely to be used frequently on containers
+packages. But an instance of any Ada language-defined container would always
+conflict with another if both used a package contents renaming construct -- 
+they both would contain the non-overloadable constant No_Cursor, for one
+example.
+
+Since type renaming only renames subprograms that are related to the renamed
+type(s), the scope of conflicts is much more restricted. (In the motivating
+case of types declared in a generic instantiation, there cannot be any
+conflicting operations declared before the instance.) Moreover, having two
+subprograms with the same name and profile, but different purposes, is a
+problem regardless of how the subprograms are called. One of the subprograms
+ought to be changed in such a case anyway. In addition, if the routines
+actually have the same function (as might happen if a previously separate
+routine is added to a generic unit), the error will point out the duplicate
+declaration (and removing it would not affect clients). Thus, an error in a
+type renaming probably really reflects an error (either of design or
+duplication), and thus will not be common.
+
+Thus we judge that the maintenance hazards from the proposed type renaming
+construct are low enough to live with, while the hazards from a package
+contents renaming are unacceptable.
+
+[Aside: This analysis suggests that no one should use constants of an ADT in a
+package specification, as such constants are not overloadable. Instead, a
+parameterless function should be used; such a function would be made visible
+by "use all type" and renamed by type renaming, while neither happens for a
+constant. In a perfect world, objects would overload like functions (the fact
+that a constant can be replaced by a function shows a model for doing so), but
+this seems too risky for Ada at this time. So one should avoid constants if
+the equivalent function would be primitive.
 
 If this feature is adopted, the author feels that we ought to consider changing
 the constants in the containers packages to functions (with Global => null to
@@ -879,5 +894,42 @@
 declaration to use this new construct. (Probably can't do that for the old
 one, sadly, as that could add a lot of operations to the spec and possibly be
 incompatible if someone manually added them somewhere.)
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, April 21, 2017  1:31 PM
+
+> However, I'm suspicious that this was just a bad workaround for the 
+> fact that neither co-derivation (AI12-0226-1) nor type renaming 
+> (AI12-0229-1) exists in Ada.
+
+I think you mean AI12-0223-1 ("The co-dervtion [sic] problem").
+
+You should correct the references to that AI in AI12-0229 (two refs in the
+!proposal), and also correct the misspelling in AI12-0223's !subject. :-)
+
+BTW, I find AI12-0229 appealing.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, April 21, 2017  1:31 PM
+
+> I think you mean AI12-0223-1 ("The co-dervtion [sic] problem").
+> 
+> You should correct the references to that AI in AI12-0229 (two refs in 
+> the !proposal), and also correct the misspelling in AI12-0223's 
+> !subject. :-)
+
+I guess this shows that (a) one should never assume that they know an AI
+number, and that (b) I need to recheck subjects multiple times, because
+they're always wrong somehow, and (c) keying a misspelling is always
+difficult (derivation is misspelled in that subject, but not THAT bad
+ - the 'a' is not missing).
+ 
+> BTW, I find AI12-0229 appealing.
+
+Better than appalling ;-)
 
 ****************************************************************