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.