Multiple return values...
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Thu Mar 15 19:26:55 PDT 2012
On 3/15/12 5:44 PM, foobar wrote:
> On Thursday, 15 March 2012 at 18:23:57 UTC, Andrei Alexandrescu wrote:
>>
>> I understand how the draw of reaching for new syntax is extremely
>> alluring. I used to fall for it much more often, but over years I have
>> hardened myself to resist it, and I think that made me a better
>> language designer. In this stage of D, I think we should all have an
>> understanding that adding syntax is not a win. Instead, it is an
>> acknowledgment that the existing language, for all its might, is
>> unable to express the desired abstraction. This is sometimes fine
>> (such as in the case of introducing multiple new symbols from one
>> tuple), but generally the question is not "why couldn't we add syntax
>> X?" but instead "why should we add syntax X?"
>>
>>
>> Andrei
>
> I agree that this is an acknowledgement of the current language's
> inability to express the abstraction. That's why many people ask for it
> to be added in the first place. We should add this syntax because it
> *is* impossible ATM to implement the required abstraction.
I think this is a reasonable request:
(auto a, b) = fun();
--->
static assert(fun().length == 2);
auto __t = fun();
auto a = __t[0];
auto b = __t[1];
To express the idiom in the example, the programmer needs to do the
expansion by hand, which is verbose and introduces unnecessary symbols.
So the language as is has an expressiveness problem (albeit not a
pernicious one) that is nice to solve.
It doesn't seem to me this is a reasonable request:
a, b = b, a;
--->
auto __t0 = b;
auto __t1 = a;
a = __t1;
b = __t0;
This is because the alternative swap(a, b) is not only competitive, but
arguably better at least in some respects.
> 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?
3. Function overhead is solved by inlining, not by adding new features.
That improves all functions, not only swap.
Andrei
More information about the Digitalmars-d
mailing list