CVS difference for ais/ai-00318.txt

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

--- ais/ai-00318.txt	2003/10/29 22:54:12	1.4
+++ ais/ai-00318.txt	2003/11/27 02:01:15	1.5
@@ -1823,3 +1823,113 @@
 
 ****************************************************************
 
+From: Dan Eilers
+Sent: Thursday, October 30, 2003, 8:01 PM
+
+The initial proposals for AI-318 involved changes to the syntax
+of a function specification, such as using OUT instead of RETURN.
+The current proposals don't.  The only proposed syntax changes are
+in the body of a function.
+
+This makes it impossible for the caller to know that this is a
+special return-in-place function, which would seem to be necessary
+in order to use different calling conventions.  Note that the caller
+can't just go by the return type being limited, because the AI is
+intended to also eliminate the copy-back for non-limited types.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 30, 2003, 8:32 PM
+
+I *think* that's intentional. The majority of functions return by-copy
+types, and for those, it makes no difference (at least, it better not). For
+other types, most compilers already use an in-place function convention in
+most cases; and those that don't (i.e. Janus/Ada) probably would be better
+off changing to use one. So, it seems that for most calls, any performance
+changes would be in the direction of faster (and possibly larger) code.
+
+But any performance incompatibilities ought to be investigated throughly.
+I've already complained about performance incompatibilities with this
+proposal (see the mail thread of May 2003 in the AI); Tucker's response is
+essentially that compilers will optimize the calling conventions, and the
+ugly cases are rare. Since that *is* an incompatibility, it should be
+discussed in the AI.
+
+We've already asked for implementation reports on this AI, since several
+implementors expressed concern about the cost of the convention. I'm sure
+we'd welcome one from you as well.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 30, 2003, 8:56 PM
+
+It is true that a single calling convention must be used.
+This implies some overhead on calling functions with a
+return-by-reference type, but the presumption is that these
+are very rare at the moment.  The presumed model is that the caller
+specifies a storage "area" (or equivalent), and a flag indicating
+whether the storage area *must* be used, or simply *may* be used.
+(I believe this is discussed in the AI already.)
+
+If used in a context where a new object is being initialized
+(e.g. a component of an aggregate, initialization expression
+for a limited object, or an initialized allocator), the specified
+storage area must be used.  If used in another context
+(e.g. in a renaming, as an IN parameter, or as an operand of some construct
+like a membership test), then the storage area need not be
+used, and returning an existing object is allowed.
+
+Currently there is an accessibility check on returning a preexisting
+return-by-reference object.  That check would be expanded to
+include a check on whether returning an existing object is permitted.
+Right now the check is officially a run-time check, but it is
+generally easy to perform at compile-time (or instantiation time).
+It would become a real run-time check with this change.
+
+The underlying presumption behind all this is that the existing
+capability to return existing objects by reference is of relatively
+little use, and it is reasonable to largely ignore this capability,
+and focus on being able to use functions with limited result types as
+"constructors."  The existing capability would be preserved, but
+perhaps might even deserve to be made obsolescent.
+
+The existing capability provides very little value over what can
+be done with returning an access value, whereas the new capability
+provides significant value as part of making limited types more
+useful.
+
+> ... Note that the caller
+> can't just go by the return type being limited, because the AI is
+> intended to also eliminate the copy-back for non-limited types.
+
+This is meant to be an optimization.  There is no guarantee
+that copy-back is eliminated for non-limited types.
+The presumption is that for most functions returning
+large objects of known size, the caller already passes in
+the address of a place where the return object should be
+placed.  This new syntax would simplify using that space
+directly within the function body, rather than doing another
+copy.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, October 30, 2003, 8:42 PM
+
+> It is true that a single calling convention must be used.
+> This implies some overhead on calling functions with a
+> return-by-reference type, but the presumption is that these
+> are very rare at the moment.  The presumed model is that the caller
+> specifies a storage "area" (or equivalent), and a flag indicating
+> whether the storage area *must* be used, or simply *may* be used.
+> (I believe this is discussed in the AI already.)
+
+That seems a nasty incomaptibility. I don't like to see a feature of relatively
+minor importance (in my view) causing an implementation incompatibility of
+this magnitude, potentially requiring reocmpilation of existing code that
+does not use the new feature, and invalidating libraries.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent