H. S. Teoh ![H. S. Teoh's Gravatar profile Gravatar of H. S. Teoh](//www.gravatar.com/avatar/62cf361f36fd5885c467c7f5d7d49fa4?d=identicon&s=80)
Posted in reply to Adam D Ruppe
| 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!
|