On Thursday, 3 April 2025 at 12:40:54 UTC, GrimMaple wrote:
> ...
> ```d
> int t = 1;
> auto z = t++ + ++t;
> ```
> Should explicitly state that:
> ```
> Warning: variable `t` is modified several times within one sequence point, consider refactoring.
> ```
>...

For me the real risk is here:

import std;

void foo(int a, int b){
    writeln(a+b);
}

void main(){
    int t = 1;
    t = 1; foo(t++,++t);
    t = 1; foo(++t,++t);
    t = 1; foo(t++,t++);
}

prints:
4
5
3

Yes I know the problem and the convention and even the appealing for some people with this pre / pos increment.

But in college I felt the pain for poor people learning and programming for the first time and facing things like this.

Matheus.

On 4/3/25 11:33, Dennis wrote:
> On Wednesday, 2 April 2025 at 20:14:48 UTC, Timon Gehr wrote:
>> Right. Documenting an inconsistency does not make it consistent. Language warts are death by a thousand cuts, they conspire together to make the language hostile to users.
> 
> While I don't think the breakage argument is particularly strong, I don't consider this a 'language wart'.
> ...

I disagree. It's different from C#/Python/... for _no good reason_. It's incidental language complexity.

> First of all, anyone who designs code to only work when the side effects in an argument list are executed in a particular order is, to put in Walter's terms, a 'no hire' for me. I'd consider the side effects to be unordered just like in C, and D's 'left-to-right' specification is simply a courtesy giving more consistent behavior across compilers. The same way D initializes `char` to 0xFF and `float` to nan not to be useful, but just as something more predictable than garbage memory. (Although I'm not a fan of this, I wish everything was 0 initialized by default).
> ...

Therefore the breakage argument is really weak. Anyway, there are use cases where evaluating in source order is just more convenient for inspection e.g. logging.

>> I am also just not a big fan of accident-driven language design where compiler bugs are codified into the spec.
> 
> Second of all, this is not a right characterization. That specification was written before named arguments existed, and never explicitly stated whether the order was relative to the argument list at the call site or the formal parameter list. It didn't have to, since they'd always be the same. Updating it to say something different as a new feature enters the language is not the same as 'codifying a compiler bug in the spec'.
> 
> Now you might say: even if the spec is not precise, clearly it was always intended that side effects are always executed in lexical order of the source code.

Yes, I am indeed saying that. At least that was what we had discussed on the newsgroup and what I had implemented in my frontend before the spec was updated with this abomination:
https://dlang.org/spec/expression.html#order-of-evaluation

> But that brings me to the third point:
> 
> Named arguments were explicitly designed to have equivalent behavior to struct initializers, so they could supersede them. And as mentioned before, struct initializers also use the order of the declaration for side effects.

Which is bad.

> Same for array initializers.

Which is bad.

> In fact, D is full of syntactic sugar for function calls (UFCS, property syntax, operator overloading) which in the end is always equivalent to the de-sugared function call.
> 
> ```D
> import std.stdio: writeln;
> 
> struct S {
>      this(int x) {writeln("S(", x, ")");}
>      auto opBinaryRight(string op)(T a) => this;
> }
> 
> struct T {
>      this(int x) {writeln("T(", x, ")");}
> }
> 
> void main() {
>      T(2) * S(1); // equivalent to S(1).opBinaryRight(T(2));
>      // prints:
>      // S(1)
>      // T(2)
> }
> ```
> 
> So changing the order of evaluation for named argument would be inconsistent with everything else in the language.

Those are all language warts. So is the fact that for AssignExpression the order is still implementation-defined.

On Thursday, April 3, 2025 3:33:30 AM MDT Dennis via Digitalmars-d wrote:
> First of all, anyone who designs code to only work when the side effects in an argument list are executed in a particular order is, to put in Walter's terms, a 'no hire' for me. I'd consider the side effects to be unordered just like in C, and D's 'left-to-right' specification is simply a courtesy giving more consistent behavior across compilers.

Part of me thinks that we should have randomized the order of evalutation with every run of the compiler just to shake out code that relies on it. Having it be defined to be left-to-right certainly helps with consistency, but I completely agree that code shouldn't be relying on it - if nothing else, because it's a bad habit to get into given that there are other major languages which don't follow it.

- Jonathan M Davis

On 4/3/25 19:19, Jonathan M Davis wrote:
> On Thursday, April 3, 2025 3:33:30 AM MDT Dennis via Digitalmars-d wrote:
>> First of all, anyone who designs code to only work when the side
>> effects in an argument list are executed in a particular order
>> is, to put in Walter's terms, a 'no hire' for me. I'd consider
>> the side effects to be unordered just like in C, and D's
>> 'left-to-right' specification is simply a courtesy giving more
>> consistent behavior across compilers.
> 
> Part of me thinks that we should have randomized the order of evalutation
> with every run of the compiler just to shake out code that relies on it.
> Having it be defined to be left-to-right certainly helps with consistency,
> but I completely agree that code shouldn't be relying on it - if nothing
> else, because it's a bad habit to get into given that there are other major
> languages which don't follow it.
> 
> - Jonathan M Davis
> 
> 
> 

This is insane. Just don't allow any non-identifier arguments at that point.

On 4/3/25 20:28, Dennis wrote:
> On Thursday, 3 April 2025 at 17:08:57 UTC, Timon Gehr wrote:
>> Those are all language warts.
> 
> That's a fair position, but it changes some key facts.
> 
> This is no longer about an accident in the implementation of the recently added named arguments being codified in the spec.

I do not really think it is important if the accident is in the named argument implementation or in the thing that named arguments have been deliberately implemented to be consistent with. I also do not want to disparage any of the existing implementation efforts, the spec has been a moving target.

This is simply about a commitment that had been made on the newsgroup _to change any the existing behavior deviating from left-to-right_ that has had only partial follow-through so far, and is now being walked back in the spec instead of just a simple: "we have not done it yet because it did not seem important enough and we prioritized other things".

> Instead, it's cementing a de-facto standard from since the beginning of dmd. A bad standard, but it's not trivial to revert it everywhere. Given that we all seem to agree that argument evaluation order is more about convenience than being a key ingredient for correct programs, that should help you understand Walter's decision making.

No. If that is the reason, then why say it is about not breaking code.

Anyway, one does not have to commit to doing it oneself or think it is important in order to agree it is a good thing to be done in general.