D has become unbearable and it needs to stop

harakim harakim at gmail.com
Wed Jul 5 09:50:55 UTC 2023


On Thursday, 8 June 2023 at 15:50:22 UTC, Steven Schveighoffer 
wrote:
> On 6/8/23 11:21 AM, Adam D Ruppe wrote:
>> On Thursday, 8 June 2023 at 15:00:04 UTC, Steven Schveighoffer 
>> wrote:
>>> In this case, `__traits(getAttributes)` was *wrong*, so a bug 
>>> is being fixed. How do we fix bugs like this without using 
>>> deprecations and eventual removal?
>> 
>> The problem is that there is no easy migration path for the 
>> cases where it actually did work just fine. The update 
>> required an extra static if branch added to each use for a 
>> generic loop.
>
> You mean, it happened to work because of the ordering of the 
> overloads? This is the nature of things that do something 
> incorrect in the face of ambiguity.
>
> This very much reminds me of the cycle detection problems I 
> fixed. Cycles wouldn't get detected, because the algorithm was 
> flawed. Fix the algorithm, and now "working" code breaks 
> because there actually is a cycle. What do we do about it?
>
> The answer at the time was to introduce a ridiculous 
> deprecation system, where I implemented both the correct 
> algorithm and the incorrect algorithm, and ran *both*. Then if 
> they disagreed, still allow it and print a deprecation message.
>
> In my estimation that is what is happening here -- you are 
> relying on a faulty implementation, and that reliance is being 
> deprecated.
>

This article has stuck with me over the years: 
https://arstechnica.com/gadgets/2022/10/windows-95-went-the-extra-mile-to-ensure-compatibility-of-simcity-other-games/

That is what made Windows successful. It was what made .NET and 
Java successful. You can write a program and then you have a 
program.

If someone at my work removed a field that I was using from a 
database or an optional field from an API, I would flip out. I 
have never seen removing "useless" or "ambiguous" features as a 
good thing if people are actually using them. If that's the case, 
then you have to go out and talk to them and get them to agree 
first because you're the one who screwed up. Otherwise, you leave 
it as it is.

I see this has been brought up, but why not use compiler flags? 
It's a win for everyone. You do have some extra code in the 
compiler until the next major version, but refer back to my Sim 
City example. That's the price of being a stable tool.

That's it for my reply, but I also have a few questions:
1. If I wanted to be a contributor and understand the dmd 
codebase and be able to understand the core team's perspective, 
how would I start?
2. How would I join the meeting with the core team where they go 
over things?
3. Could the people who want a stable language theoretically 
declare one version of it stable and maintain it themselves?



More information about the Digitalmars-d mailing list