On Monday, 12 June 2023 at 12:12:18 UTC, Martyn wrote:

That is exactly what I would like to see as well! This versioning scheme is much better than what we have right now stabilizing the language changes...

On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

Case in point:

https://issues.dlang.org/show_bug.cgi?id=23989

On Tuesday, 13 June 2023 at 14:17:33 UTC, deadalnix wrote:

Interesting...

Anyway, this is a general question for all, and I understand I am (likely) showing my n00bness as a D developer.

(Afterall, one of the reasons I am skeptical using Dlang for production is precisely this reason... no LTS and, more specifically, mangling of libraries tested under different dmd builds)

For example.. lets say:-

I have created a D application using DUB. So far, so good. It builds with the latest version of dmd I installed earlier today (2.104.0)

Ok, now I need to use some libraries. DUB is great for this! However, when I search for packages, how do I know which version they support?

   2.104.0?
   2.103.0?
   2.102.0? (???)

Are we expecting maintainers of these libraries to keep them up to date monthly? Lets be honest.. if I need to include 3 DUB projects into my application then what are the chances they have been tested on 2.104.0? It is highly unlikely. The next question is - what version should I be using? Atleast 4 versions old?

One DUB package might have been updated 4 months ago. While I can predict the version they last used, it does not mean thats that the version tested by the maintainer. Should I have to predict this? Should I have to look at their code? Each DUB package have their own versioning which does not help, either.

Now, imagine the difficulties of an application with 3 or 4 DUB packages. Each library being released/updated at different times and lord knows what version they were last tested on. Will they all work with 2.104.0?

Because of potential breaking changes for each new release... could I end up with ProjectA being OK but not another, while experimenting with different dmd versions?

There is a reason why LTS releases exist. Look at other languages. Java, .NET, C++. Look at other projects like Linux or Blender. Could you imagine Blender users going by monthly builds only. Blender would fall apart and fast!

Again, if we had LTS builds, our libraries can target those specifically. It also makes it easier to maintainers to plan ahead for the next LTS. As my previous post suggested, the version of the libraries can start with the LTS version. It makes it so easy to know if your version is supported, etc.

Just my 2 cents and I apologise if I am really missing the point. I am sure atleast some of this lands with a number of people.

On Tuesday, 13 June 2023 at 15:34:28 UTC, Martyn wrote:

Mangling is not really the problem I think. If the ABI changes you can still rebuild everything, including the cached dependencies that would break; Not great but not a big problem. I think the discussion is more about how the language features are different from a version to another.

On Tuesday, 13 June 2023 at 15:34:28 UTC, Martyn wrote:

Actually, dub already allows specifying toolchain requirments. https://dub.pm/package-format-json.html#toolchain-requirements . But it hardly helps with solving the issue of breakage, as some packages may require different versions of frontend and there is no way to solve it. Actually, someimtes, even dub packages themself can break because they depend on different versions of the same package, but at least 3rd party is usually strong enough in guaranteeing compatibility within certain major version.

I don't know what the "expectancy" is, but talking with a lot of D developers led me to one conclusion: everyone expects you to have your own standard library. And then everyone expects you to use as little of the language as possible. And then everyone expects you to write your own code anyway, because there's an informal agreement that "dependencies bad".

This is a chicken and egg problem, really. Is there no packages because nobody writes them because "dependencies bad", or are "dependencies bad" because every existing one just breaks?

I don't have to imagine this -- dlangui has 9 dependencies. I went through great lengths to extract them from dlangui project itself (they were initially copy-pasted into a 3rdparty folder), and I'm beginning to regret this. If any of the dependencies break, or stop updating, I'm stuck with an old compiler version essentially. And it's not like replacing dependencies is easy when they are so scarce.

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 agree that some form of LTS is needed, but I don't think it's going to happen with D. After all, it's not that the lack of LTS is causing issues. We could be upgrading compilers monthly without issue if those releases provided some strong guarantee of at least not changing something that results in API changes. After all, changing, eg, std.xml to undead.xml isn't that devastating, and doesn't affect third-party that much. I even stressed that D has become unbearable, as in it didn't introduce much breakage a few years back. Though, a stable release would still be greatly appreciated.

Yes, that is the whole point of this thread. To ask for some sort of stability in the D ecosystem. Because, practically, there isn't just "the latest version", there are 10 to 20 versions of D in the wild at the same time, and it's impossible to deal with.

On Tuesday, 13 June 2023 at 16:57:15 UTC, GrimMaple wrote:

Although I have done my own standard library myself. I have plenty of other reasons to do so. One of them was for the number of platforms I needed to support (including my own Druntime). I can't see any other reason why would anyone other would need their own.

On Tuesday, 13 June 2023 at 16:57:15 UTC, GrimMaple wrote:

Thank you for taking the time to respond.

Yes, your answers are confirming a number of things.. and that my 'imagine' case(es) are, in fact, a reality - especially for bigger-than-average maintainers... like dlangui.

The "dependencies bad" mindset has a place for certain projects but should this be the case for many D projects? Sure D is great for low-level solutions and certainly allows this approach. It is a great replacement for C, etc. However D is also a high-level language and its ease of use should be comparable to C#, Java, etc - especially with their respected package repositories.

With dependencies, the footprint on D executable, etc, should still be tiny compared to others. In most cases, the "dependency bad" needs to die in D.

"I went through great lengths to extract them from dlangui project itself (they were initially copy-pasted into a 3rdparty folder), and I'm beginning to regret this. If any of the dependencies break, or stop updating, I'm stuck with an old compiler version essentially. And it's not like replacing dependencies is easy when they are so scarce."

This pretty much hit the nail on the head for me. I do not want to write commercial projects only to keep having to handle dependency/compiler problems. Reality is - **** happens, and time is money. Do I really have the time to deal with this (potential) problem happening out of nowhere?

"I agree that some form of LTS is needed, but I don't think it's going to happen with D"

This is too bad. I hope you are wrong about this. I have been on-and-off with D for a few years, now. I felt D was going to be the "one true language" for me, whether low or high level. Some projects are coming my way believing the time have arrived to finally move to D.. to write some server-side applications... I just feel like I will hit a brick wall with the things mentioned above. Honestly it's making me bite the bullet and go a step closer to Ru$t (though they were having their own problems with trademark backlashes.. lol)

"Yes, that is the whole point of this thread. To ask for some sort of stability in the D ecosystem"

I just wanted it laid out in plain text. It seems to me the majority are on the same wavelength of what LTS means. I just wanted to clarify this.

Happy hacking.

On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

Add the deprecation directory and save the deprecation function code there.
If the deprecated function is placed separately in thedeprecated directory, even if it is deprecated, some people are unwilling to improve and can continue to keep the deprecated function available. As long as the code is there, it can be compiled and passed.
In this way, it is equivalent to updatingonly adding functionality, without damaging functionality.

On Wednesday, 14 June 2023 at 01:22:00 UTC, zjh wrote:

With the deprecated directory, there is no need to maintain the LTS version because you have never deleted functionality!.

On Tuesday, 13 June 2023 at 16:57:15 UTC, GrimMaple wrote:

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