D has become unbearable and it needs to stop

[Chris Katko]

On Tuesday, 13 June 2023 at 16:57:15 UTC, GrimMaple wrote:
> `icontheme` dependency of dlangui is exactly what you describe. 
> The maintainer refused to adapt to changed `alias this` rules, 
> and I will have to figure something out eventually. Possibly, 
> it's another project that I will have to maintain by myself 
> because of silly breakage.

I just did a grep -nr in my git directory, I've got 26 uses of it 
just in the few projects I have installed on this netbook. That's 
insane to delete a feature because "it's not clearly defined".

If it's not clearly defined... then you _define_ it, not _delete_ 
it. Especially after years of the feature being around.

Imagine if we dropped strings from D because there's some use 
case that's undefined.

If the blog/patchnotes stated workaround [1] is basically... 
implementing alias this with a template mixin... then make it use 
that mixin internally and keep "alias this". I mean, if that 
template mixin is a viable alternative, then it's clearly a 
solvable problem. If it's NOT a viable alternative, then why are 
we deleting a feature with no workaround? And likewise, if alias 
this is so dangerous, how is it safe/okay to recommend using the 
mixin version?

And as for "gotchas" with alias this use, 90% of the D language 
is one big gotcha. Put code in a deconstructor? Better know 
exactly what kind code causes allocations because writeln(x, " = 
", y) will be fine, but god forbid you accidentally write 
writeln(x ~ " = ", y) and segfault with no stacktrace as you're 
trying to learn a new language.

imported std.regex? You just doubled your compile time. There's a 
gotcha.

Tell any other object about yourself in the constructor? 
segfault. Because your object isn't constructed till _after_ the 
constructor runs. There's a gotcha.

Not adding a feature I can use like [private] for classses (if I 
understand correctly, they don't do anything in D), I can stand. 
Not everyone agrees on what features are valuable. But actually 
__removing__ features I'm using to make my code cleaner with no 
compiler switch to keep the feature at my own peril? That's 
incredibly frustrating.

Language users are NOT going to take more than one or two 
instances of deleting features before they leave. Why risk 
writing code in a language when literally any other feature you 
use may be on the chopping block next?

[1] 
https://dlang.org/changelog/2.103.0.html#dmd.deprecate-alias-this-for-classes