D has become unbearable and it needs to stop

[FeepingCreature]

On Sunday, 18 June 2023 at 13:59:07 UTC, Dany12L wrote:
> On Saturday, 17 June 2023 at 06:25:26 UTC, Walter Bright wrote:
>> Frankly, anyone who wants to can step up and pick a version of 
>> D, declare it to be LTS, and pull only bug fixes to it, can do 
>> so.
>
> After all this talk another unnecessary change that will break 
> the code in the user has been accepted
>
> https://github.com/dlang/dmd/pull/15319
>
> Please Walter Bright check this...

I'm not sure about that one myself, even though I did it. (See my 
comment.) Right now, I'm mostly just hoping that nobody is 
calling private methods in that way. As I said, I could split it 
out into a separate deprecation but that would require undoing 
the error unification in the fix PR. And the whole this error 
happened like three separate times is because this check is split 
over a bunch of separate codepaths, so I'd hate to contribute to 
making it worse.

That said, the language working as specified and documented is 
not an "unnecessary change".

I think we're running the risk of falling into a hole of "code is 
fragile and unmaintainable, so don't change anything ever." 
Longstanding bugs going unfixed is a major contributor to code 
that is fragile and unmaintainable, because you cannot trust what 
it says! Not to mention this makes D a hellhole for new people to 
learn.

Years ago, I noted that learning D is not primarily a matter of 
learning the language. The language is intuitive and 
straightforward. Instead, learning D is primarily a matter of 
memorizing all the diverse places where the language is *not* 
intuitive and in fact is broken and you just have to avoid them. 
I think cutting down on that is more important than preserving 
the very specific ways in which you are sometimes permitted to 
call a private method if you have placed an unrelated public 
method in the right location in your code.

That said, honestly, look at the bug. They're calling a private 
method! That means they, or at least somebody, intended it to 
*not* be called! Even on its own merits, I really think this is a 
case where an error is just more valuable to the developer than 
no error.