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

[Timon Gehr]

On 09/24/2012 11:22 PM, Nick Sabalausky wrote:
> On Mon, 24 Sep 2012 15:27:19 +0200
> Philippe Sigaud <philippe.sigaud at gmail.com> wrote:
>
>> On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
>> <SeeWebsiteToContactMe at semitwist.com> wrote:
>>
>>> That said, I'm not necessarily opposed to the strict separation if
>>> we had a good candidate for built-in tuple literal syntax. But *if*
>>> the best we have is parens (and maybe there *is* something better?)
>>> then maybe this would be an acceptable way to achieve it?
>>
>> If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
>> element tuples), then maybe *for once* a simple syntax change could
>> solve them? I know syntax proposals are a dime a dozen in this
>> newsgroup, but why not here, to avoid the ((1)) problem?
>>
>
> I'm all for that. In fact, I was was just about to post the same
> suggestion.
>
> My bikeshed is colored one of these:
>
> (:1,2)
> (|1,2)
>

At that point you might as well just use

import std.typecons : q = tuple, Q = Tuple;

Q!(int, int) foo(){
     return q(1, 2);
}

If built-in tuples are not going to look like

(1, 2)

then imho we might as well leave them out, while still addressing
unpacking in the locations bearophile has designated.


> Minimal syntax (one extra character), no ambiguities with anything
> else AFAIK. Looks kinda funny, but so did !() at first and we all got
> used to that.
>
>> For example choosing { 1, 2} to represent a tuple?
>
> I like it, but what about zero-element tuples vs empty code blocks?
> (Or is it ok because code blocks can't be used inside, or as,
> expressions?)
>
> Also, it may be too easy to accidentally get mixups between one-element
> tuples and certain one-statement blocks:
>
> { foo(); }  // Block
> vs
> { foo() } // Either a tuple or a forgotten semicolon
>
> Not sure if that's a big enough deal, though.
> ...

q(foo())