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.