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

--- ai05s/ai05-0067-1.txt	2008/02/05 04:40:31	1.3
+++ ai05s/ai05-0067-1.txt	2008/02/05 06:33:09	1.4
@@ -1019,22 +1019,66 @@
 
 ****************************************************************
 
-From: Robert A. Duff
-Sent: Monday, January 4, 2008  1:11 PM
-****************************************************************
+From: Randy Brukardt
+Sent: Monday, January 4, 2008  10:29 PM
 
-From: Robert A. Duff
-Sent: Monday, January 4, 2008  1:11 PM
-****************************************************************
+> > I think we use the term "unspecified" rather than
+> > "implementation dependent" in the RM.
+>
+> OK.
 
-From: Robert A. Duff
-Sent: Monday, January 4, 2008  1:11 PM
-****************************************************************
+Either that or "implementation-defined". In this case, "unspecified" is
+better, I think.
+
+> > You start talking about a "thunk" in the AARM note
+> > somewhat out of the blue.  Is there really a need
+> > for a thunk?  If so, I think you need to explain
+> > what it does.  I suspect that some implementations
+> > might prefer to create "pseudo" storage pools
+> > rather than thunks, though that is hopefully not
+> > semantically significant.
+>
+> That "thunk" is an editing mistake.  I think I thunk about the GNAT
+> implementation details too much ;-), and then eliminated those details,
+but
+> missed that one.  The basic idea is that a storage pool is passed in.  One
+> common "storage pool" is the "allocate-on-secondary-stack" storage pool.
+> I think this is optimized in the GNAT case by passing various flags that
+bypass
+> the actual pool -- e.g. a flag might say "allocate on secondary stack".
+> I don't remember the details of the GNAT implementation, but anyway, the
+AARM
+> doesn't need to talk too much about those optimization details. Maybe just
+> mention the possibility.
+
+OK.
+
+> There's one more occurrence of the term "thunk", which I really mean.
+>
+> > Overall, the solution you propose seems reasonable.
+> > It will probably require some rewording in AI-66
+> > (which I sent around last night).
+>
+> Right, I noticed that, but didn't say anything.
+
+We'll have to reconcile a number of these AIs when I integrate this stuff.
+That's what I get paid for, usually. :-)
+
+> I'm glad you say "reasonable".  I'm thinking there are two objects, the
+return
+> object and the newly-created object that it turns into.  In my AI writeup,
+I
+> said "becomes", but I wish there were a more evocative word -- "morphs
+into"
+> or "magically transforms itself" or (from the minutes) "poofs"?
+
+I prefer "morphs into". As long as it's in the notes. "Becomes" sounds too
+much like normal assignment (":=" is supposed to be read "becomes" after
+all - 2.2(13)).
+
+I'm made these minor changes to the AI that we'll discuss in Florida. (And
+reworded to use "inherently limited type", otherwise we'd still have the bug
+from AI05-0059-1.)
 
-From: Robert A. Duff
-Sent: Monday, January 4, 2008  1:11 PM
 ****************************************************************
 
-From: Robert A. Duff
-Sent: Monday, January 4, 2008  1:11 PM
-****************************************************************
\ No newline at end of file