Walter Bright wrote

> it isn't easy to do

If it is not easy to define the order for the specs,
then it will not be easy to learn,
then near to nobody will know of or rely on the definition in the
specs.

Remember that even M$ recommends to fully parenthese expressions <because others might not know how to evaluate expressions without parentheses>.

You once said, that you want to prohibit the upcoming of D-guru's. But if you yourself are not able to immediately sketch such order here, then you have the proof of upcoming gurus.


If it is not easy to code then above arguments holds for compiler writers too.


-manfred

Bruno Medeiros wrote:
> Frits van Bommel wrote:
>> Bruno Medeiros wrote:
>>> As we know, in C/C++ there are a lot of cases where the order of
>>> evaluation of an expression is undefined.
>>>
>>>   i = i++;
>>>   c = a + (a = b);
>>>   func(++i, ++i);
>>>
>>> D goes one step further by defining that any such behavior is illegal:
>>> "Unless otherwise specified, the implementation is free to evaluate the
>>> components of an expression in any order. It is an error to depend on
>>> order of evaluation when it is not specified." in
>>> http://www.digitalmars.com/d/expression.html .
>>
>> Actually, if I read that right it just says that the order of evaluation is undefined and should not be relied upon. Just like C/C++.
> 
> Read the paragraph ahead in the doc. In D that is considered a language(i.e. compile) error and so the compiler can issue an error. In C/C++ it is merely undefined program behavior, the code remains compilable.

IIRC[1] the C++ standard includes "causes a compile error" as one of the possible consequences of undefined behavior. I'm not sure about C.


[1] I've been staying away from C++ since I started using D, so this is by no means a given...

[snip]
>> Unspecified evaluation order is an optimization opportunity.
>> For instance, the most efficient parameter evaluation order can be dependent on the calling convention, which is platform-dependent. For instance on x86 and amd64 platforms the most efficient evaluation order can very well be to evaluate right-to-left, since typical calling conventions specify the last argument is to be pushed onto the stack first[1]. (There are good reasons for that, mostly to do with varargs)
[snip]
> 
> In that case, it is possible for the compiler to detect if the evaluation order matters, and if it doesn't (currently the only allowed situation in D), it can push the arguments in any order it pleases him.

<nitpick> Actually, if you check the spec it says the compiler is allowed to issue an error if it detects the _result_ of the expression depends on evaluation order. It doesn't seem to mention side-effects at all, so evaluation order is technically allowed to matter (though it's still an error to _depend_ on it). Well, unless you count side-effects as part of the "result" of an expression... </nitpick>

> Even if that wasn't possible, I'm not sure that with modern CPU technology, right-to-left calling conventions (last argument on top) would be any slower to call with an left-to-right eval order, than with an undefined order. Then again, I'm no Assembler or CPU optimization expert, so correct if I'm wrong.

Nor am I, but I've inspected a lot of the assembly code generated for my programs and often the DMD and GDC optimizers apparently decided to evaluate (roughly) right-to-left...

Manfred Nowak wrote:
> Walter Bright wrote
> 
>> it isn't easy to do
> 
> If it is not easy to define the order for the specs,

It's easy to define the order. It is not so easy to implement it.

Manfred Nowak wrote:
> Walter Bright wrote
> 
>> it isn't easy to do
> 
> If it is not easy to define the order for the specs,
> then it will not be easy to learn,
> then near to nobody will know of or rely on the definition in the specs.
> 
> Remember that even M$ recommends to fully parenthese expressions <because others might not know how to evaluate expressions without parentheses>.
> 
> You once said, that you want to prohibit the upcoming of D-guru's. But if you yourself are not able to immediately sketch such order here, then you have the proof of upcoming gurus.
> 
> 
> If it is not easy to code then above arguments holds for compiler writers too.
> 
> 
> -manfred

I agree.  Furthermore, I strongly think it should be left as is.  Why, because when I comeup against weird code like that, I don't want to have to consult the spec.  Its like implicit casting, if you don't know what is happening your going to have a terrible time figuring out what is happening.

This is one area where I think D could do a lot more to help the programmer avoid mistakes.

Furthermore if its difficult to implement, you've just made D harder for someone else to implement.

Please reconsider putting this in.

-Joel

Walter Bright wrote
> It's easy to define the order.

Then please do so right now.

-manfred

Manfred Nowak wrote:
> Walter Bright wrote
>> It's easy to define the order.
> 
> Then please do so right now.

Then I'd have a pile of bug reports because it isn't so easy to implement.

Walter Bright wrote

> Then I'd have a pile of bug reports because it isn't so easy to implement.

Why that, when it isn't in the specs, only in this forum, and declared as a draft definition?

Please do not declare that the thinking capabilities of average D-users are that low.

-manfred

Manfred Nowak wrote:
> Walter Bright wrote
> 
>> Then I'd have a pile of bug reports because it isn't so easy to
>> implement.
> 
> Why that, when it isn't in the specs, only in this forum, and declared as a draft definition?
> 
> Please do not declare that the thinking capabilities of average D-users are that low.
> 
> -manfred

I don't think he means bugs in users' code (although there would probably be a handful of them, most likely quick-fixes though).  I think he actually means bugs in the compiler, which are worth more time spent investigating implementation details to avoid.

-- Chris Nicholson-Sauls

Manfred Nowak wrote:
> Walter Bright wrote
> 
>> Then I'd have a pile of bug reports because it isn't so easy to
>> implement.
> 
> Why that, when it isn't in the specs, only in this forum, and declared as a draft definition?
> 
> Please do not declare that the thinking capabilities of average D-users are that low.
> 
> -manfred

Someone with a non-low average thinking capability (*grin* :) ) would easily deduce that the evaluation order will be the same as any other modern programming language (not just Java, but C#, Python, even Ruby, have all the same evaluation order). The rule in a general sense is:
  Evaluate operands in the same order as the associativity rule of the operator.

So stuff like this:
  c = a + (b = c);
evaluates in this order:
  a
  c
  b
  (b = c)
  a + (b = c)
  c
  c = a + (b = c)

A function call, since it is basicly an operator that takes a function value and arguments as operands, works in the same rule. So:
  func(++i, ++c);
evaluates:
  func
  ++i
  ++c
  func(++i, ++c)

I don't think there is any significant learning process involved here. If you know the associativity rules (which you should), then the evaluation order is simply what naturally follows from there. You don't have to memorize a whole different set of rules. In fact the assignments are basicly the only operators where the operands are evaluated right-to-left.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Frits van Bommel wrote:
> Bruno Medeiros wrote:
>> Frits van Bommel wrote:
>>> Bruno Medeiros wrote:
>>>> As we know, in C/C++ there are a lot of cases where the order of
>>>> evaluation of an expression is undefined.
>>>>
>>>>   i = i++;
>>>>   c = a + (a = b);
>>>>   func(++i, ++i);
>>>>
>>>> D goes one step further by defining that any such behavior is illegal:
>>>> "Unless otherwise specified, the implementation is free to evaluate the
>>>> components of an expression in any order. It is an error to depend on
>>>> order of evaluation when it is not specified." in
>>>> http://www.digitalmars.com/d/expression.html .
>>>
>>> Actually, if I read that right it just says that the order of evaluation is undefined and should not be relied upon. Just like C/C++.
>>
>> Read the paragraph ahead in the doc. In D that is considered a language(i.e. compile) error and so the compiler can issue an error. In C/C++ it is merely undefined program behavior, the code remains compilable.
> 
> IIRC[1] the C++ standard includes "causes a compile error" as one of the possible consequences of undefined behavior. I'm not sure about C.
> 
> 
> [1] I've been staying away from C++ since I started using D, so this is by no means a given...
> 

I haven't read about C++ in detail, only C. But in both cases (and sometimes here in the NG too) I often see the documents call "undefined behavior" to thing they should call errors. They refer to these concepts almost interchangeably, whereas they are not. They overlap a lot but they are not the same, there is a subtle difference.

Dereferencing a trash pointer, for example, *is* an error. It *causes* undefined behavior, but it *is not* merely undefined behavior: it *can crash* your program.
On the other hand if do:
  func(i++, i++);
where func simply prints prints its arguments, I will have undefined program behavior, but no program error : that code *can not ever* crash the program. (altough it is still likely a *conceptual* error)

This is a minor nitpick, since in practice both should be equally avoided, but that subtle difference is still there.


> [snip]
>>> Unspecified evaluation order is an optimization opportunity.
>>> For instance, the most efficient parameter evaluation order can be dependent on the calling convention, which is platform-dependent. For instance on x86 and amd64 platforms the most efficient evaluation order can very well be to evaluate right-to-left, since typical calling conventions specify the last argument is to be pushed onto the stack first[1]. (There are good reasons for that, mostly to do with varargs)
> [snip]
>>
>> In that case, it is possible for the compiler to detect if the evaluation order matters, and if it doesn't (currently the only allowed situation in D), it can push the arguments in any order it pleases him.
> 
> <nitpick> Actually, if you check the spec it says the compiler is allowed to issue an error if it detects the _result_ of the expression depends on evaluation order. It doesn't seem to mention side-effects at all, so evaluation order is technically allowed to matter (though it's still an error to _depend_ on it). Well, unless you count side-effects as part of the "result" of an expression... </nitpick>
> 

To "depend on the evaluation order" is to have the evaluation order matter. :)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D