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

[deadalnix]

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