D has become unbearable and it needs to stop

[H. S. Teoh]

On Fri, Jun 09, 2023 at 12:14:35AM +0000, Adam D Ruppe via Digitalmars-d wrote:
[...]
> I'm pro breaking changes that move toward something better that have a
> good migration path.

+1, me too.


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

Yes.


> 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.

I actually think alias this for classes is a bad thing.  I used it in my
own code and liked it at first, but as I gained more experience with it,
I discovered that it was only good for short term convenience, over the
long term it becomes a source of confusion and maintenance headaches. So
I'm not against removing it per se.  However, as you said, there is no
migration path, and that's bad.  I did have to rewrite a good chunk of
code in my own project after the deprecation came into effect. In some
parts it wasn't too pretty, though overall I did feel that the code
improved afterwards.  Still, the extent to which I used it was quite
limited; I can imagine the frustration if I had to deal with a much more
extensive usage.


> 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.

I never dared use getAttributes on overload sets, because reading the
docs made it clear to me that it simply wasn't designed to handle that,
and probably would exhibit quirky behaviours and be unstable across
releases.  (It's a scary thing when the docs describe something and
fails to describe corner cases that immediately pop up to mind when you
read it -- obviously it didn't even occur to the author that it could be
a problem, which gives you a lot of confidence in the implementation --
NOT.)  I'm glad I exercised caution. :-/


> 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.

With the recent proliferation of attributes and their frequent
breakages, I've become more and more hesitant to use them in my own
code. If it's a template and the compiler deals with them for me, then
fine. But I'm feeling more and more resistance to writing them myself,
in the fear that it will come back one day to bite me from behind at the
least convenient moment.  (One time I had a user request that got
stalled because of a deprecation kicked in for an old-ish project that I
hadn't touched in a while.  What could have been a 5-minute bugfix
turned into a several-hour detour to fix deprecations.  It was Not
Fun(tm).)


Another example of a deprecation of questionable value, though in
Phobos, not the language itself, is the approxEqual -> isClose
deprecation a couple of years ago.  I mean, there's totally a good
reason behind it, but the fact that it broke lots of perfectly-fine old
code was Not Nice.  And the deprecation message was unclear about how to
fix the code -- I had to go out of my way to look up the docs for
isClose (and the choice of name IMO was unfortunate) just to figure out
what exactly I needed to do to replicate the old behaviour of
approxEqual.  That was Not Nice when I needed to recompile an old
project just for a 1-line bugfix.  I ended up spending hours on it,
rather than just a 5-minute quick fix.  I have absolutely no problem
with using isClose for new code, but why gratuitously break old code for
no reason?  A lot of the breakage in my code was in old unittests --
verifying computations for values that are known to work correctly with
approxEqual. Just because approxEqual had some bad corner cases -- which
my unittests did NOT touch -- is no reason to break it for ALL old code
in existence that uses it.  Just undocument it so that new code won't
use it anymore.  It doesn't cause problems with anything else; its
continued existence in Phobos doesn't cause any detriment.  Old code
would continue to compile, and that's a Good Thing(tm).


> > 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...

Dependencies *are* evil.  (Dependency hell is an NP-complete problem.
That says something.)  I've come to adopt the practice of keeping a
local copy of all my 3rd party dependencies in my workspace, just so the
code will still exist 10 years down the road when I suddenly need to
recompile old code again.  I've been burned a couple of time with non-D
projects (these were C and C++ projects) where upstream of a 3rd party
lib either vanished into the ether, or decided to go ahead with a
totally breaking change with no migration path, AND the old version of
the code conveniently doesn't exist anymore.  I swore to myself that
I'll never rely ever again on the existence of some library source code
that only lives on some server somewhere out there on the 'Net.  If I
ever need a 3rd party lib, I'd better be darned sure I'm relying on a
local copy of it that's gonna STAY put forever (not just in some
temporary dub cache that can randomly get removed), until I don't need
it anymore.


That said, though, if D is forever going to remain in the realm of DIY
code, then it's never going to grow beyond what it is now.  We NEED to
promote more collaborative libs, not discourage them through gratuitous
breakages.


> > 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.

Also, some things you may not be able to fix yourself.  E.g. if the lib
was a crypto lib and you're not a crypto expert.  Or fixing a
deprecation issue requires deep knowledge of the internal workings of
the lib, which you may not have.


T

-- 
That's not a bug; that's a feature!