On 09/24/2012 03:41 AM, Jonathan M Davis wrote:
> 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.
>

Of course it does. Some values are returned by dereferencing a hidden argument.

> It's function arguments that should be evaluated left-to-right.
>
> - Jonathan M Davis
>

On 09/24/2012 04:27 AM, Timon Gehr wrote:
> On 09/24/2012 03:41 AM, Jonathan M Davis wrote:
>> 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.
>>
>
> Of course it does. Some values are returned by dereferencing a hidden
> argument.
>

Nevermind. In the general case, a temporary still has to be generated
because of aliasing issues.

>> It's function arguments that should be evaluated left-to-right.
>>
>> - Jonathan M Davis
>>
>

On 9/23/12 9:27 PM, deadalnix wrote:
> I understand the trouble here. But why divide and conquer is preferable
> here over a static foreach over the tuple ?

There are fewer data dependencies, which results on faster execution on today's CPUs.

Andrei

On 9/23/12 9:31 PM, 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 ?

Currently probably neither :o). I used to oppose it, then I figured it's actually nice because of things like:

int[int] stuff;
stuff[42] = stuff.length;


Andrei

On 9/23/12 10:15 PM, Timon Gehr wrote:
> 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?

Not to the best of my knowledge. I'm not even sure it's always the case.

Andrei

On Sun, Sep 23, 2012 at 04:40:34PM -0400, Andrei Alexandrescu wrote:
> I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this:
> 
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19

+1 to getting rid of the comma operator. (OK, just deprecation, but that's a good step.) I always felt it's one of those unnecessary holdovers from C. We don't need a comma operator. The only use cases I've ever seen of it is in specific contexts (such as for-loops) where suitable, relatively confined, syntax extensions would take care of everything without the invasiveness of having an entire operator.


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom

On Sun, 23 Sep 2012 21:30:08 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Sun, Sep 23, 2012 at 04:40:34PM -0400, Andrei Alexandrescu wrote:
> > I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this:
> > 
> > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
> 
> +1 to getting rid of the comma operator. (OK, just deprecation, but that's a good step.) I always felt it's one of those unnecessary holdovers from C. We don't need a comma operator. The only use cases I've ever seen of it is in specific contexts (such as for-loops) where suitable, relatively confined, syntax extensions would take care of everything without the invasiveness of having an entire operator.
> 

I saw it once in an earlier revision of RDMD from about a year ago. It was an awkward usage (IMO) and isn't there anymore.

So basically, I agree that it's not particularly useful ;)

On Sun, 23 Sep 2012 18:48:22 -0400
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
> 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.
> 

I think one of us is missing something, and I'm not entirely sure who.

As I explained (perhaps poorly), the zero- and one-element tuples *would still be* tuples. They would just be implicitly convertible to non-tuple form *if* needed, and vice versa. Do you see a reason why that would *necessarily* not be the case?


> I think it's safe to just not even discuss it.

A nice way to put it :/  Part politician perhaps? ;)

Glad to hear that comma operator won't be depreciated.

On 23/09/12 22:40, Andrei Alexandrescu wrote:
> I discussed this with Walter, and we concluded that we could deprecate
> the comma operator if it helps tuples. So I started with this:
>
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
>
> Unfortunately, I started much cockier than I ended. The analysis in
> there fails to construct a case even half strong that deprecating the
> comma operator could significantly help tuples. Well it essentially
> concludes that tuples are mostly fine as they are, and attempts to
> embellish them syntactically are marred with unexpected problems.
> Nevertheless, I sure have missed aspects all over, so contributions are
> appreciated.
>
>
> Thanks,
>
> Andrei

Regarding the comma operator: I'd love to deprecate it, but even if we don't, could we at least ensure that this kind of rubbish doesn't compile:

void main()
{
  int x;
  x > 0, x += 5;
}

At present, because comma expressions are expressions, not statements, the "x > 0" doesn't generate a "statement has no effect" error, despite the fact that it is meaningless and gets completely discarded.