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

[Nick Sabalausky]

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)

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.

> > Ie:
> >
> > // (3) is polysemous: Either int or (int)
> > int   a = (3);  // Normal value
> > (int) b = (3);  // One-element tuple
> > auto  c = (3);  // Default to normal "int"?
> 
> For the third case, I'd say it defaults to a tuple. But then again,
> using another syntax solves this problem.
> 

My reasoning for defaulting to non-tuple was minimizing code breakage
and simplifying the handling of general expresssions that happen to
involve parens (ie, it's always a mere expression until it gets
assigned/passed-in to a tuple). But I agree, just using a syntax that's
unambiguous from the start is better.