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

[Timon Gehr]

On 09/23/2012 10:58 PM, foobar wrote:
> On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu wrote:
>> I discussed this with Walter, and we concluded that we could deprecate
>> the comma operator if it helps tuples. So I started with this:
>>
>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
>>
>> Unfortunately, I started much cockier than I ended. The analysis in
>> there fails to construct a case even half strong that deprecating the
>> comma operator could significantly help tuples. Well it essentially
>> concludes that tuples are mostly fine as they are, and attempts to
>> embellish them syntactically are marred with unexpected problems.
>> Nevertheless, I sure have missed aspects all over, so contributions
>> are appreciated.
>>
>>
>> Thanks,
>>
>> Andrei
>
>
> Yay! vote += infinity
>
> Regarding specifics,
> I'd argue that (int) should be a perfectly valid construct.

If so, it should be the same as int.

> I don't see what's confusing about that.

Those are currently both valid and give the same result:

int.max
(int).max

Anyway, the tuple type should resemble the tuple expression
syntactically.

> I also am opposed to the idea to limit
> tuples to 2 or more elements. On the contrary, I root for the clean
> semantics of having a proper unit type represented as () instead of the
> horrible C semantics of the 'void' type. Just make void an alias to ()
> for backwards compatibility.

You mean, alias () to 'void' for backwards compatibility. How would
that give 'clean semantics'? It's just syntax. Or is it about void
supporting 'expand'? I don't think that makes sense.

void foo(){}

void main(){
     void[] x = new int[42];
     foo(x[0].expand); // whut?
}


> Also, why the need to special case the for loop? the increment part can
> be a regular tuple since the for loop doesn't assign the value of the
> expression. for (int i, j; cond; i++, j++) {}

I assume Andrei intends the enclosing parens to be mandatory.

> I'd suggest looking at functional implementations such as ML or Haskel[l] for more inspiration.

They just do the two most obvious things. (well, Haskell has to answer
some questions related to the evaluation model that are irrelevant for
D.)

Neither one has a syntactic construct for building a single element tuple.

> Also, I want to add that type declarations should be changed from statements to expressions so that we could do:
> auto tup = (3, "hello");
> (int num, string s) = tup; // num == 3, s == "hello"

I'd support the addition of declaration expressions (mainly for using
them in conjuncts of if conditions), but this is not necessary to
enable what you show above.