Order of evaluation for named arguments

[Timon Gehr]

On 4/2/25 21:57, Walter Bright wrote:
> 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.
> ...

That does not rule out fixing bugs, I hope.

> 
>> 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.
> ...

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.

> 
>> 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 :-)
> 

I simply do not understand what goes into the decision-making on this. 
There does not seem to be any consistent line or standard.

It is certainly also true that I do not agree with it.