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