September 24, 2012
On 09/24/2012 02:00 AM, deadalnix wrote:
> Le 24/09/2012 01:28, Timon Gehr a écrit :
>> I agree with Andrei. Single element tuples need to support the same
>> operations as tuples of other arities do.
>
> Obviously it should. The whole point is that you can implicitly cast a 1
> element tuple into the element and vice versa.
>
> like :
> (int) a = (3); // a is a tuple of 1 element.
> int b = a; // Implicit tuple unpack.
> a = b; // Implicit tuple packing.


Well, I do not want parentheses to randomly hide members.

(a ~ b).length
September 24, 2012
Le 24/09/2012 02:21, Timon Gehr a écrit :
> On 09/24/2012 02:00 AM, deadalnix wrote:
>> Le 24/09/2012 01:28, Timon Gehr a écrit :
>>> I agree with Andrei. Single element tuples need to support the same
>>> operations as tuples of other arities do.
>>
>> Obviously it should. The whole point is that you can implicitly cast a 1
>> element tuple into the element and vice versa.
>>
>> like :
>> (int) a = (3); // a is a tuple of 1 element.
>> int b = a; // Implicit tuple unpack.
>> a = b; // Implicit tuple packing.
>
>
> Well, I do not want parentheses to randomly hide members.
>
> (a ~ b).length

Then it easy to add a comma to create a one element tuple. IE:

(a ~ b).length == a.length + b.length
(a ~ b,).length == 1
September 24, 2012
On 09/24/2012 02:28 AM, deadalnix wrote:
> Le 24/09/2012 02:21, Timon Gehr a écrit :
>> On 09/24/2012 02:00 AM, deadalnix wrote:
>>> Le 24/09/2012 01:28, Timon Gehr a écrit :
>>>> I agree with Andrei. Single element tuples need to support the same
>>>> operations as tuples of other arities do.
>>>
>>> Obviously it should. The whole point is that you can implicitly cast a 1
>>> element tuple into the element and vice versa.
>>>
>>> like :
>>> (int) a = (3); // a is a tuple of 1 element.
>>> int b = a; // Implicit tuple unpack.
>>> a = b; // Implicit tuple packing.
>>
>>
>> Well, I do not want parentheses to randomly hide members.
>>
>> (a ~ b).length
>
> Then it easy to add a comma to create a one element tuple. IE:
>
> (a ~ b).length == a.length + b.length
> (a ~ b,).length == 1

The motivation for having these conversions was syntactic ambiguity.

If there is none, just do it like this:

(create_tuple,)
get_value[0]
September 24, 2012
On 9/23/12 7:08 PM, deadalnix wrote:
> Le 24/09/2012 00:48, Andrei Alexandrescu a écrit :
>> This notion a lot of trouble with it; I think it's safe to abandon it
>> entirely.
>>
>> Once a one-element tuple becomes equivalent to the actual item, there's
>> an explosion of trouble and special cases in the language and in code
>> that uses it. For example, divide and conquer code that manipulates
>> tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to
>> cases in which the slices are no longer tuples, and so on. And that's
>> only the beginning.
>>
>
> This is a very weak point. In most cases, divide an conquer with tuple
> don't even make sense.

The example came from min() applied to built-in "T..." tuples. I've implemented it a few times, and I recall at some point there was a compiler bug related to zero-length tuples. It was rather awkward to address. But there are many other cases. In my opinion, introducing a change of phase at length=1 is just causing trouble.

Andrei


September 24, 2012
On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
> On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
>> I believe it is currently left-to-right for D, in all kinds of
>> expressions, but DMD does not implement it yet.
>
> Yeah, I thought it was already defined.

Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first.

Andrei
September 24, 2012
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
> On 9/23/12 7:08 PM, deadalnix wrote:
>> Le 24/09/2012 00:48, Andrei Alexandrescu a écrit :
>>> This notion a lot of trouble with it; I think it's safe to abandon it
>>> entirely.
>>>
>>> Once a one-element tuple becomes equivalent to the actual item, there's
>>> an explosion of trouble and special cases in the language and in code
>>> that uses it. For example, divide and conquer code that manipulates
>>> tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to
>>> cases in which the slices are no longer tuples, and so on. And that's
>>> only the beginning.
>>>
>>
>> This is a very weak point. In most cases, divide an conquer with tuple
>> don't even make sense.
>
> The example came from min() applied to built-in "T..." tuples. I've
> implemented it a few times, and I recall at some point there was a
> compiler bug related to zero-length tuples. It was rather awkward to
> address. But there are many other cases. In my opinion, introducing a
> change of phase at length=1 is just causing trouble.
>
> Andrei
>

I understand the trouble here. But why divide and conquer is preferable here over a static foreach over the tuple ?

Additionally, what lead me to think the idea is good is how tuple can be used to call function, or to extend the opDispatch feature to templated calls.

I didn't wanted to go into such details, because I wanted to test several idea before doing a proposal. A lot of options are possible here, and interaction with other part of the language are everywhere.
September 24, 2012
Le 24/09/2012 02:44, Timon Gehr a écrit :
> The motivation for having these conversions was syntactic ambiguity.
>
> If there is none, just do it like this:
>
> (create_tuple,)
> get_value[0]

As I answered to Andrei, my motivation isn't related to syntax ambiguity, and I actually don't care what the syntax is as long as it isn't terribly twisted.
September 24, 2012
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
> On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
>> On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
>>> I believe it is currently left-to-right for D, in all kinds of
>>> expressions, but DMD does not implement it yet.
>>
>> Yeah, I thought it was already defined.
>
> Actually it's right to left for assignments. In expr1 = expr2, expr2
> gets evaluated first.
>
> Andrei

Is it by implementation or by design ?
September 24, 2012
On Monday, September 24, 2012 03:31:08 deadalnix wrote:
> Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
> > On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
> >> On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
> >>> I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet.
> >> 
> >> Yeah, I thought it was already defined.
> > 
> > Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first.
> > 
> > Andrei
> 
> Is it by implementation or by design ?

Design. It makes no sense for the left-hand side of an assignment to be evaluated before the right-hand side.

It's function arguments that should be evaluated left-to-right.

- Jonathan M Davis
September 24, 2012
On 09/24/2012 03:14 AM, Andrei Alexandrescu wrote:
> On 9/23/12 7:20 PM, Adam D. Ruppe wrote:
>> On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote:
>>> I believe it is currently left-to-right for D, in all kinds of
>>> expressions, but DMD does not implement it yet.
>>
>> Yeah, I thought it was already defined.
>
> Actually it's right to left for assignments. In expr1 = expr2, expr2
> gets evaluated first.
>
> Andrei

Is this documented anywhere?