D has become unbearable and it needs to stop

[Adam D Ruppe]

On Thursday, 8 June 2023 at 20:08:51 UTC, Dukc wrote:
> That being said, I don't think language instability is the 
> problem. We want D to develop after all, and the language 
> already tries to be reasonably backwards-compatible. It's just 
> the natural price of using a language that is still developing.

I'm pro breaking changes that move toward something better that 
have a good migration path.

I'm against breaking changes that don't do those thing.

The alias this for classes thing has no migration path and isn't 
moving to something better. It has no actual technical 
justification, being an arbitrary removal. This is not a step 
forward.

The getAttributes of an overload set had no easy migration path 
for the cases where it worked just fine (nor the other cases 
really, the "right" way is a pain in the butt consistently, and 
this deprecation is not a step toward fixing that pain), and the 
deprecation message itself is buggy giving false positives that 
are a pain to work around! This is a step backward.

The changes to `in` are obnoxious since it keeps changing the 
definition to protect people who weren't following the spec while 
punishing people who were. But... it is potentially leading to 
something valuable and is pretty easy to migrate things, so I'll 
cut it a bit of slack. While it annoys me, on balance, I can 
actually see this as worthwhile.

> But the less library dependencies you have, the less problems.

Yeah, dependencies are evil, but again this is a bit of a 
problem: D works best when everyone does their own thing. But one 
of the paths to bigger adoption is more collaborative libs...

> Sometimes it may be more practical to bundle the library source 
> in your codebase (as opposed to DUB registry) so you can fix it 
> yourself. That has its downsides but it's still a valid choice.

When your thing is open source it tends to become a problem 
eventually whether you like it or not.