CVS difference for ais/ai-00304.txt

Differences between 1.4 and version 1.5
Log of other versions for file ais/ai-00304.txt

--- ais/ai-00304.txt	2004/02/21 04:15:10	1.4
+++ ais/ai-00304.txt	2004/03/02 04:45:00	1.5
@@ -912,5 +912,111 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Monday, February 23, 2004  4:53 PM
 
+Please note that the original basis for the proposal about "aliased" types
+was to allow non-tagged types to "work right" in generics and composition.
+We now require all language-defined non-limited types to have an "=" that
+composes properly.  This forces the implementation of bounded strings
+to require a default initialization to all nulls of the nested array.
+Having the "=" for appropriately marked non-tagged types compose properly
+would solve this and similar problems.
+
+I believe the AI explains why using "aliased" as the marking for this
+makes sense, and that it solves various other outstanding issues in a relatively
+economical way.  The basic idea was to give the programmer more control
+when they need it.  It would be helpful if rather than accusing the AI
+of containing "crud designed to work around an obvious deficiency" that
+reviewers read AI-304 and comment on what "crud" it actually contains. ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 23, 2004  5:29 PM
+
+I certainly have sympathy with solving the "=" problem. But this solution
+seems awfully heavy for just that purpose, and it seems that solving the "="
+is a minor side-effect (which is backwards in my view). My initial response
+to this suggestion (recorded in the !appendix) was "... seems like killing a
+gnat (er, fly) with a cannon.", so that, at least, hasn't changed.
+
+In addition, this solution to the "=" fails the "Bob Duff Orthogonality
+Test". That is, you have to specify a property that you don't (necessarily)
+want (in Ada 95, it's "tagged", here it would be "aliased") in order to get
+the correct behavior. And "aliased" objects will generate worse code in
+general (because of the assumption of aliasing, requirements for alignment,
+etc.) than regular objects, so it's not something that you would not care
+about using.
+
+Moreover, having adding "aliased" to a type change the behavior of "=" seems
+weird and potentially error-prone (particularly if maintenance removes
+"aliased" to get better code generation).
+
+So I remain to be convinced.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Tuesday, February 24, 2004  2:11 PM
+
+I have to agree with Tucker here.  There is a definite need for aliased
+types that are not tagged types--the example of an array with aliased
+components is the one that has burned me the most, but I am sure there
+are others.  Allowing/requiring equality to compose "correctly" for such
+types makes sense, or more to the  point, doing the opposite makes no sense.
+
+Allowing users to declare types as aliased is a language extension, but
+I don't see it as something new, I see it as a part left out of Ada 95
+that is necessary to make access parameters, 'Access, and
+'Unchecked_Access usable.
+
+If some people feel that the only use for access parameters is to get
+around the rule about in only parameters for functions, they are missing
+all of the other things that can be done with access parameters.  And
+why are they missing them?  Because the current rules make using
+'Address the only possible way to do many things that a (safe) 'Access
+could do.  If this AI passes, a lot of code that is currently using the
+"Rosen trick" will get fixed.  Good.  It is not safe, as having a
+(possibly private) type that is always passed by reference would be.  If
+some want to go the whole nine yards and say that assignment to
+components of a parameter of and aliased type passed by access is
+allowed, I won't fight it.  But I do think that 'requiring' the type
+safe version of the Rosen trick is just as good:
+
+type Foo is aliased array....;
+
+function Bar(X: in Foo) return Integer is
+    type Foo_Pointer is access Foo;
+    FP: Foo_Pointer := Foo'Access; -- or 'Unchecked_Access if required.
+begin
+    FP(1,1) := ...;
+    return 3;
+end Bar;
+
+(I am assuming that if Foo'Access returns a value of type access to
+constant, then Foo'Unchecked_Access will return access to varible. If
+not we are stuck with the Rosen trick.)
+
+Or of course, we could change the type of a random number generatior to
+be aliased, and change Random to take an access parameter.  With this
+AI, that is an upwardly compatible change.  Then people could use access
+parameters of an aliased type where they want to insure that things are
+passed by reference, and the whole religious war thing goes away.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 25, 2004  4:27 PM
+
+Huh? Calls to an access parameter would need 'Access (or 'Unchecked_Access) --
+that hardly would be an upwardly compatible change.
+
+It's precisely the 'noise' that access parameters force on users of an
+interface that I hate. That's why I almost never use access parameters in
+public interfaces -- because it puts a burden on the users of an abstraction.
+'Aliased' types would reduce that burden a little, but by no means eliminate
+it.
+
+****************************************************************
 

Questions? Ask the ACAA Technical Agent