Order of evaluation for named arguments

[Walter Bright]

On 4/1/2025 4:44 PM, Timon Gehr wrote:
> Why do cautionary C++ tales apply elsewhere but not here?

It all depends on the magnitude of the damage done. There are tradeoffs in 
everything, nothing is a pure win. D is full of compromises.


> The 
> evaluation order used to be _not specified_... The spec plainly allowed for 
> breaking code that depends on evaluation order!

Right. And that was when we were breaking existing code with every new release. 
We agreed a year or two ago to not continue doing that.


> There are degrees to things, and tradeoffs. It's not black and white. Some 
> benefits are more important than others, and some drawbacks are less important 
> than others.

Absolutely right. Most of my career is programming with implementation defined 
evaluation order - it's deeply ingrained in me to not rely on it. 
Implementation-defined also means inconsistency.

But I propose to document the existing behavior, so it is consistent and 
reliable. Consistency is a valuable characteristic.


> In the end it is up to you, I just don't understand it.

If I may be so bold, I think you do understand it, you just don't agree with it :-)