On Tuesday, 1 April 2025 at 19:00:49 UTC, Walter Bright wrote:
> On 3/30/2025 6:21 PM, Jonathan M Davis wrote:
>> It might, but most folks don't even realize that named arguments are a thing
>> in D, and most code doesn't rely on the order of evaluation of the arguments
>> to a function. As such, I would expect that the amount of code that would
>> actually break would be extremely small (and possibly zero).
>> 
>> Most bug fixes risk silently breaking some piece of code that accidentally
>> relied on the broken behavior, and I think this is a case where the odds of
>> it actually causing problems are sufficiently low that it's worth just
>> making it all consistent - and the sooner we do it, the less likely it is to
>> break any code.
>
> It's a good argument, but we really have no idea how much code depends on named arguments. I'm also really tired of the vitriol we get when breaking existing code.

Will it be more or less vitriol than what you get from all the people who expect the arguments to be evaluated left to right? I mean there seems to be a pretty solid consensus that is what is expected. This fails pretty bad on the principle of least surprise right?

And as it is now you have to look up the definition of the function to understand what order the arguments are evaluated. You cant know just by looking at the call code, you need to look at the function definition.

It's unnecessary cognitive load, and unintuitive. And you will probably have to listen to people complain about it for years to come, just like the "strict private" crap.

You want to have years and years of flame wars over argument evaluation order?

Make the hard but correct decision.

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.

On Tuesday, 1 April 2025 at 18:58:08 UTC, Walter Bright wrote:
> ...
> Breaking existing code has repeatedly driven people away from D.
> ...

I'm not saying you're wrong but is there any data about this? - I mean after "n" breakages we had a decrease in numbers of users?

I pretty sure complains about breakages exists, as some developers leaved D community because restraint or DIP bureaucracy, but I think in the end most people would prefer a coherent language than another C++ one.

Will users leave because this broke up software or fell safe that it follows a pattern?

The problem I see with situation like this, is that we can't complain later when some streamer decide to use a language and show its problems for a large audience, and just after that people start to realize that we should have fixed this earlier.

Finally just tried C# and the same example given by Steve:

using System;				
public class Program{
	public static int x;
	public static void foo(int a, int b){
		Console.WriteLine("a: " + a + " b: " + b);
	}
	public static void Main(){
		foo(b:++x,a:++x);
	}
}

Prints:

a: 2 b: 1

So, arguments are evaluated left to right.

Matheus.

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

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.

On Wednesday, 2 April 2025 at 11:11:24 UTC, matheus wrote:
> On Tuesday, 1 April 2025 at 18:58:08 UTC, Walter Bright wrote:
>> ...
>> Breaking existing code has repeatedly driven people away from D.
>> ...
>
> I'm not saying you're wrong but is there any data about this? - I mean after "n" breakages we had a decrease in numbers of users?

I'm not sure there was any estimation..
People were pissed off because of breaking tooling/projects every release..

I'm not sure how bad people will feel about breaking once a year with clear suggestions (semi-automatic scripts) of fixing breaking parts

Seems not so many complaints in Rust/Zig.. and I think they have more production code than D (even Zig which is not even 1.0)

On Wednesday, 2 April 2025 at 20:14:48 UTC, Timon Gehr wrote:
> On 4/2/25 21:57, Walter Bright wrote:
>>
>
> I simply do not understand what goes into the decision-making on this. There does not seem to be any consistent line or standard.

There's an easy hacky fix. That's the decision making process.