On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky <seewebsitetocontac...@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 };