On 09/06/2023 7:43 AM, Hipreme wrote:
> The thing is that D doesn't have structure enough to get a LTS.

Not true.

Iain maintained the LTS version for gdc for a very long time.

We can do it, but as far as I'm concerned its up to him if we proceed and how.

On Thu, Jun 08, 2023 at 09:05:18PM +0000, Ernesto Castellotti via Digitalmars-d wrote: [...]
> GDC starting from GCC 12 version started to get really interesting (so much so that now I've replaced LDC with GDC in production because it's much easier for me to handle for my embedded programming) because it is updated to recent D versions.

I stuck with LDC mainly for the ease of cross-compiling to Windows. All I need is to download the LDC releases for Linux and Windows, modify a config file, and it's ready to go.  Cross-compiling with GDC is much trickier to setup, and can be fragile if you're not 100% sure what you're doing.


> I believe that no one can ever reward enough Iain Buclaw for the great work he did with GDC, having a D compiler on GCC mainline is just amazing.

To get a language into GCC mainline takes dedication and skill. The GCC codebase isn't the most friendly to work with if you're not familiar with it. And getting code to the point that it gets accepted into mainline takes some real skillz.  But it also takes time -- IIRC it took many years for Iain to push it through to GCC mainline.  That takes dedication: long, dogged persistence.  It's really rare to find someone who can do both.  Iain is a real treasure to the D community.


T

-- 
Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert

On Thursday, 8 June 2023 at 21:33:37 UTC, H. S. Teoh wrote:
> I stuck with LDC mainly for the ease of cross-compiling to Windows. All I need is to download the LDC releases for Linux and Windows, modify a config file, and it's ready to go.  Cross-compiling with GDC is much trickier to setup, and can be fragile if you're not 100% sure what you're doing.

Yeah great point, I hadn't thought about Windows because it's been years since I've done anything on Windows and in any case I've never used D for Windows programs only C++ :-(

On Thursday, 8 June 2023 at 21:11:24 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Iain maintained the LTS version for gdc for a very long time.

And I maintained compatibility with that version in my libs until quite recently (of course some of them still do, but my test system uses gdc 12 instead of 9 now so the gdc9 support is prolly gonna start slipping). It actually wasn't even that hard.

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.

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!

Thanks for spending the time to post this. We're going to take it to heart.

On 6/8/2023 7:56 AM, GrimMaple wrote:
> The truth is, I've been nagging about LTS branches, and I've been nagging directly to Mike about it, and it went nowhere.

It's not about not caring about it. It's just that I can't see how it would be effective. Making LTS versions balkanizes the language into multiple languages, which will play hell with 3rd party library maintenance.

Clearly, the deprecation scheme is not serving our users well. We'll have to find a better way.