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

--- ai12s/ai12-0229-1.txt	2017/04/21 03:41:41	1.1
+++ ai12s/ai12-0229-1.txt	2017/04/21 05:43:53	1.2
@@ -799,10 +799,11 @@
 From: Randy Brukardt
 Sent: Thursday, April 20, 2017  10:39 PM
 
-Here is a write-up of a possible type renaming facility. I didn't try to write
-formal wording, so it is somewhat of a bastard write-up at the moment. But it
-seemed worthwhile to do this exercise to have something concrete to discuss to
-determine if there is enough interest in the idea to proceed.
+Here is a write-up of a possible type renaming facility. [This is version /01
+of the AI - Editor.] I didn't try to write formal wording, so it is somewhat
+of a bastard write-up at the moment. But it seemed worthwhile to do this
+exercise to have something concrete to discuss to determine if there is enough
+interest in the idea to proceed.
 
 Note that for Ada 2012, we tried to defined integrated packages for this need.
 When that didn't work out, we invented "use all type". This essentially takes
@@ -816,5 +817,67 @@
 
 As always, comments and brickbats welcome (the latter so long as they miss
 me. ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 20, 2017  11:07 PM
+
+[Why I am I answering Brad's editorial review comment under this subject?
+Read on...]
+
+...
+> After B.5(10)
+> 
+>     type Double_Complex is new Double_Precision_Complex_Types.Complex;
+>     subtype Double_Imaginary is
+> Double_Precision_Complex_Types.Imaginary;
+> 
+> 
+> It struck me as being odd that Double_Complex is a type, whereas 
+> Double_Imaginary is a subtpe of the base type for Double_Complex. That 
+> is consistent with the original Complex and Imaginary types, but there 
+> appears to be no reason for this inconsistency between the Imaginary 
+> types and the Complex types. If there was such a reason, it may be 
+> lost in the annals of time, but if it is known, it might be good to 
+> provide some sort of AARM note as to why it was done this way.
+
+I can't say for sure why it was done this way, thus I don't think a note is
+appropriate.
+
+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.
+
+Having just written up AI12-0229-1, this looks very much like Tucker's
+motivating case for asking for type renaming. In particular, the author of
+this package appears to be wanting to get two related types and their
+primitive operations declared in the outer package Interfaces.Fortran.
+
+In Ada to date, there is no good way to do that. This example is the best of
+a bad lot. It declares all of the primitives of complex, but requires
+creating a different type to do it. And primitives of Imaginary alone are lost
+in the shuffle.
+
+If instead both types had been derived, all of the operations that are
+primitive on both types would have been inherited twice (both with the
+original and new Imaginary types). If neither type was derived, no primitive
+operations at all would be declared.
+
+A better solution than any of these would be to use the newly proposed type
+renaming:
+
+    type Double_Complex, Double_Imaginary renames
+         Double_Precision_Complex_Types.Complex,
+         Double_Precision_Complex_Types.Imaginary;
+
+This declares two subtypes and all of the primitive operations of both types.
+This eliminates the extra types and the loss of the operations on Imaginary
+alone.
+
+If we adopt AI12-0229-1, we probably ought to consider changing this new
+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.)
 
 ****************************************************************