Named return type > Out parameters
Robert Jacques
sandford at jhu.edu
Fri Nov 13 08:07:15 PST 2009
On Fri, 13 Nov 2009 07:30:55 -0500, grauzone <none at example.net> wrote:
> のしいか (noshiika) wrote:
>> Bill Baxter さんは書きました:
>>> Did go do away with the comma sequencing operator?
>>> I can't find it. That's the first thing D needs to do.
>>>
>>> Otherwise
>>> a,b = function()
>>> is difficult to make work.
>> How about redefining the comma operator as a "tuple constructor"
>> with its precedence unchanged?
>> In so doing, we may write:
>> (int, int) func(int x, int y) { return y, x; }
>> // tuple-to-tuple function
>> // (int, int) is a type tuple, "int x, int y" a named type tuple,
>> // and "y, x" an expression tuple.
>> (int, int) t = func(0, 1);
>> // t is a type-tuple-typed variable.
>> int a, b;
>> (a, b) = func(t);
>> // (a, b) is an lvalue tuple.
>
> Very yes! Of course I'd prefer to be able to write "a, b = func(t);" in
> expressions.
>
> Too bad Andrei and Walter don't seem to think these are issues. Don't
> know how they can live with that Tuple!(...) crap.
>
>> and f(0, 1) beautifully has the same semantics with f((0, 1)) by the
>> tuple flattening.
>
> Tuple flattening is bad and should be removed as quickly as possible
> from D.
Only type tuples are flattened. auto t = tuple(1,tuple(2,3)); doesn't
flatten.
As for syntax, I'd prefer using the slice operator, '..', since doing so
facilitates multi-dimensional containers.
More information about the Digitalmars-d
mailing list