Le 24/09/2012 17:24, Andrei Alexandrescu a écrit :
On 9/24/12 9:27 AM, Philippe Sigaud wrote:
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 };
I think my main problem with this is that I'm perfectly happy with the
baseline, which has "tuple(" as the left delimiter and ")" as the right
delimiter. I'd be more excited to invent notation if there was
overwhelming or at least considerable evidence that the notation
considerably helps certain use cases, or is very frequent. As things
are, I'd be quite "meh" about suddenly adding lenses.
Andrei
Clearly, crating a tuple that way isn't the issue. tuple() is ok.
