View mode: basic / threaded / horizontal-split · Log in · Help
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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
>
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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
>>
>
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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 ;)
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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? ;)
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Glad to hear that comma operator won't be depreciated.
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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.
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home