D has become unbearable and it needs to stop

[Dany12L]

On Monday, 19 June 2023 at 07:23:59 UTC, FeepingCreature wrote:
> 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.


I think there is a misunderstanding here, saying that a 
particular language behavior is wrong according to the 
specification is different than throwing an error in the compiler.

Is issue 21275 incorrect according to the language specification? 
Yes
Is the behavior unpredictable? No, so there is no reason to throw 
an error

Simply issue a deprecation or warning message and allow the user 
to ignore it or treat it as an error, the fact that it is against 
the specification does not prevent the compiler from generating a 
working executable with predictable behavior.

There is no reason to throw errors for these things, C/C++ 
compilers don't do that and that allow the developer time to fix 
without preventing the code from compiling.