D has become unbearable and it needs to stop

[harakim]

On Thursday, 6 July 2023 at 02:44:30 UTC, FeepingCreature wrote:
> The problem is that you're committing your whole project to 
> either having the flag set or not having it set. If some code 
> will only work with and some code only without, you're SOL. And 
> the more flags you add to the compiler, the more likely a 
> conflict becomes.

I don't see a lot of projects being so large and complex that 
someone could not realize they are using a flag and then also 
miss the behavior in testing. And if the project is like that, 
then they have the manpower to go and remove the flag. How often 
are you expecting these compiler flags to come along? The first 
requirement is that there was a bug in the compiler or standard 
library. That seems like a pretty high bar to clear, although all 
code has bugs so it does happen. The second bar is the code base 
has to be such that it *relied* on the behavior of the bug. Then 
the person who is actually building the source has to decide it's 
too difficult to fix the issue for whatever reason. How many 
flags do you think a code base will have? When I write code, I 
split it up so I could pass the flag into a payment gateway but 
not into the shipping price calculator, for example.

I think in the case that the core team made a mistake that needs 
to be fixed, a flag is a good option. And only pushing the 
removal of deprecations every few years doesn't seem like a big 
deal either. I would like to see what you all talk about at the 
monthly meetings. I would like to learn what goes into making a 
programming language that makes these things so difficult. I 
would be willing to take a long time of listening and 
understanding to figure that out. And at the end of it, I think I 
could be a bridge from the language developers to the 
discontented community members who want to see stability.