DIP19: Remove comma operator from D and provision better syntactic support for tuples

[ixid]

On Tuesday, 25 September 2012 at 10:04:46 UTC, deadalnix wrote:
> Le 25/09/2012 03:19, ixid a écrit :
>> What would a special case where the first level of tuple (with 
>> higher
>> levels being tuples in tuples) didn't require parens break? 
>> This would
>> be a beautiful syntax:
>>
>> auto a = 1, 2; // A tuple of two ints
>>
>> int, string fun(double, double d) {
>> return cast(int) (d[0] * d[1]), "hello";
>> }
>>
>> auto a, b = 1, 2; // Two ints
>> auto a = fun(1.0, 1.0); // Tuple of 1 and "hello".
>> auto a, b = fun(1.0, 1.0); // An int and a string.
>>
>
> It can get pretty confusing with , separated declarations :
>
> int a, b = 3;
>
> or worse :
>
> int a, int b = foo();
>     -->
>         (int a, int b) = foo();
>       or
>         int a, (int b = foo());
>
> and it gets worse with int a, auto b = foo();
>
> But I do agree that this is really nice in many places.

Replying to the correct post this time, sorry for the repeated 
posting.

You've shown it's clearly incompatible with the current language
and would break lots of code. What would it break if assignment
required explicit tuple brackets?

(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be
filled in order by the multiple return values of foo()

int foo() {
     return 1;
}

(int a, b) = foo(); // Also valid and only sets 'a'


int, int foo() {
     return 1, 2;
}

int a = foo(); // Also valid and 'a' takes the first tuple value

(int a, auto b) = foo(); // Evaluated left to right so 'a' will
take the first argument of foo and b will auto to a type or tuple
of what remains. It will error if there is nothing remaining for
b. This would still allow the clean expression of stand-alone
tuples and function arguments and return values.

int, string a = 1, "hello";
int, string foo(double, double a) {
    return cast(int) (d[0] * d[1]), "hello";
}

Doesn't the needs of bracketing to determine order operation,
(stuff) more or less imply that implicit conversion between one
member tuples and the type of that tuple member is a requirement?
Or would the (stuff, ) syntax be better?