On 3/16/12 6:29 AM, Manu wrote:
On 16 March 2012 04:26, Andrei Alexandrescu
<seewebsiteforem...@erdani.org <mailto:seewebsiteforem...@erdani.org>>
wrote:
A good design should strive to provide general features instead of
special cases (E.g. swap is limited to the 2-tuple case). Also, why
force an overhead of a function call on such a basic feature as
assignment? Is swap usually inlined by the compiler?
Sorry, this is grasping at straws.
1. swap can be easily generalized to take any number of arguments.
I'm very happy that's possible, we've expended great efforts on
making variadic functions as powerful as they are. But nobody asked
for swap with many arguments until now. Which segues into...
2. When was the last time you needed to swap arbitrary numbers of
elements, and so badly and frequently, you needed a new language
feature for that?
This is called a swizzle. And constantly comes up when dealing with
x,y,z,w, or r,g,b,a.
It could just as easily be expressed this way:
a,b = tuple(b,a); // swap
r,g,b,a = tuple(a,r,g,b); // swizzle
At which point this multi assignment boils down to the exact same
question of syntax as MRV return assignment. I don't really distinguish
this swap/swizzle from MRV. It all comes back to the return assignment
syntax.
Actually, as has been mentioned, swizzling can be done very nicely
inside the language.
3. Function overhead is solved by inlining, not by adding new
features. That improves all functions, not only swap.
Requiring inlining to make it efficient is not enough. The proposed MRV
ABI would solve this not only for inlines, but for all multi-assignment
type constructs, including distant function calls.
If changing the ABI is on the table, I wonder whether we can improve it
for all structures, not only for multiple return types. Overall I agree
that defining a specialized ABI for leaving multiple values on the stack
would be marginally more efficient, but (a) I don't know by how much,
and (b) I don't know whether it's worth changing the language.
Andrei
