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

[Philippe Sigaud]

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?

For example choosing { 1, 2} to represent a tuple? { } blocks in D
enclose semi-colon terminated declarations or expressions, but here
it's enclosing comma-separated expressions. And, since { } is probably
dangerous without a completly integrated type systems giving a type to
all expressions (  (){} anyone?) , why not use (| 1, 2 |), or whatever
syntax strikes our collective fancy? (I propose *not* to use < , >)

Then, the compiler has to change the way it prints its internal tuple,
to follow the new syntax.

> 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.

auto c  = (| 3 |); // or c = { 3 };