On Monday, 24 March 2014 at 13:12:36 UTC, Dicebot wrote:
> If you are not ready to break the code for it, there is nothing to discuss. It is not something to compromise about - either kill it completely, or just let it be. Anything else will make things only worse.

Actually, Andrei's solution of not being able to use the result is really nice as it allows to redefine the meaning later, as well as it limits the breakage.

On Monday, 24 March 2014 at 16:40:29 UTC, Andrei Alexandrescu wrote:
> How about
>
> tuple(1,2)    two-element tuple
> tuple(1)      one-element tuple
> (1)           simple expression
> tuple()       empty tuple
>
> Oh, wait...
>

Yes, that.

deadalnix:

>> tuple(1,2)    two-element tuple
>> tuple(1)      one-element tuple
>> (1)           simple expression
>> tuple()       empty tuple
>>
>> Oh, wait...
>>
>
> Yes, that.

99% of the problem is not in the syntax to build tuples. What's desired are mostly syntaxes to do the opposite, pulling tuples apart in a handy way.

Bye,
berarophile

On 3/24/14, 9:57 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>>> Look at some of the syntaxes here:
>>> http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax
>>>
>>> One of the syntaxes:
>>>
>>> @{}
>>> @{a}
>>> @{a, b}
>>> @{a, b, c}
>>
>> WTF???
>>
>> tuple()
>> tuple(a)
>> tuple(a, b)
>> tuple(a, b, c)
>>
>>
>> Andrei
>
> So you are saying you want to support a syntax like this?
>
> tuple(a, b, c) = myFunc();

That would be a different function but same syntax. In fact for safety I favor myFunc().scatter(a, b, c) -- Andrei

On Monday, 24 March 2014 at 18:58:52 UTC, Michel Fortin wrote:
> On 2014-03-24 16:42:59 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>
>> tuple()
>> tuple(a)
>> tuple(a, b)
>> tuple(a, b, c)
>
> struct()
> struct(a)
> struct(a, b)
> struct(a, b, c)
>
> Tuples are actually nameless structs, no?

This whole point is that this part doesn't need any language semantic addition.

An unpacking syntax is a useful addition, and not especially related to tuples, as you could unpack arrays for instance.

Andrei Alexandrescu:

> That would be a different function but same syntax. In fact for safety I favor myFunc().scatter(a, b, c) -- Andrei

That's awful :-) Are you now saying you don't want a good tuple unpacking syntax in D? Then what's the "eye to tuples" you were talking about regrding comma syntax?

Bye,
bearophile

On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu
wrote:
> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

Kill it.  I'll admit to using the comma operator on occasion, but
never for any reason that warranted it.  If there are any
lingering uses in Druntime I'm 100% for eliminating them.

On Monday, 24 March 2014 at 16:38:42 UTC, Andrei Alexandrescu wrote:
> On 3/24/14, 5:18 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>> This is nice, although I guess it will make parsing harder. It probably
>> means that the distinction between "," as operator and tuple element
>> separator will be context-dependent.
>
> No, parsing stays the same. You can think of comma returning a tuple. But for now we're forcing that tuple to never be used, so as to not change code semantics.

Ah, that's clever.

On Monday, 24 March 2014 at 20:04:23 UTC, deadalnix wrote:
> On Monday, 24 March 2014 at 18:58:52 UTC, Michel Fortin wrote:
>> On 2014-03-24 16:42:59 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>>
>>> tuple()
>>> tuple(a)
>>> tuple(a, b)
>>> tuple(a, b, c)
>>
>> struct()
>> struct(a)
>> struct(a, b)
>> struct(a, b, c)
>>
>> Tuples are actually nameless structs, no?
>
> This whole point is that this part doesn't need any language semantic addition.
>
> An unpacking syntax is a useful addition, and not especially related to tuples, as you could unpack arrays for instance.

And would also avoid memory allocation where possible.
At least as far as unpacking the results of a function are concerned.

Joseph

I just introduced one in my own code:

if (s[0] != '/', s)