Order of evaluation for named arguments

[Timon Gehr]

On 4/1/25 20:58, Walter Bright wrote:
> 
>> I am also just not a big fan of accident-driven language design where 
>> compiler bugs are codified into the spec.
> 
> Breaking existing code has repeatedly driven people away from D.

So does keeping existing broken behavior. x)

Why do cautionary C++ tales apply elsewhere but not here?

Anyway, e.g. DIP1000 deprecations are hardly comparable to what this is. 
The evaluation order used to be _not specified_... The spec plainly 
allowed for breaking code that depends on evaluation order!

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.

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