On Thursday, 28 October 2021 at 14:00:48 UTC, Robert burner Schadek wrote:

That would be cool. And it would be extra cool if it could compile the program after each iteration to verify that it actually, well, compiles.

When you think of it, this sounds like an obvious solution. Was something like this done before in some other programming language or library?

On Thursday, 28 October 2021 at 11:30:18 UTC, Ogi wrote:

The packages would not be totally locked apart:

auto dateTime = package1.getDateTime;
package2.useDateTime(*cast(std2.datetime.DateTime*)&dateTime);

This would suck of course, but at least it works. Unless the DateTime format is different between the Phobos versions, in which case more cowboying is needed. Preferably wrapped in a nice conversion function by the user.

Hopefully this would be needed only rarely. Ranges would still work from one Phobos to another because the DBI interface presumably stays the same, albeit there would be extra template bloat.

Fortunately exceptions are all inherited from the DRuntime class, so at least they will have the same base class. Assuming DRuntime version stays coupled with compiler's.

On Thursday, 28 October 2021 at 15:50:28 UTC, Dukc wrote:

That would most likely end up being the case.

On Thursday, 28 October 2021 at 14:53:26 UTC, Adam D Ruppe wrote:

I'm going to start by saying you have always been more than helpful on the forum, I respect your opinions, and most of my D problems have historically been solved by asking you or by asking someone who references something you wrote. I don't have any claim to the direction of the D language/phobos library compared to you, so this is not supposed to be prescriptive, but a different perspective.

I think the reason the most popular D libraries have just a handful of users is related to the idea that the D language maintainers should just do something and if there is a problem, make affected users come to the forum and ask for help. Why should they do that when they can easily switch to a more stable language?

I posted a post on reddit in reply to why D is not popular. I dread coming back to my projects and having to spend time to get them to recompile. I didn't include this specifically in the reddit, but the libraries are pretty bad in some cases with comments like this one, from Derelict:

Why doesn't it compile? Not even the maintainer wants to find out, what chance do I have?

D will never be popular until this problem is solved. If D wants to be a niche language with few people maintaining the entire ecosystem, rapid change is desirable. If D wants to become widespread, then it has to start viewing breaking changes as generally unacceptable and a failure of the ecosystem. For that reason, I would be very hesitant about doing something to break libraries that use std.

Auto-decoding seems like a corner case that was used for a time, but isn't used much anymore except by libraries that this forum more or less is willing to change. If that's true then I think it's worth a breaking change, but I still feel like that change needs to be viewed as a failure and retrospected upon.

I think the compiler could be smart enough to issue an error about the library change if it sees a type difference of std.X.Y and std2.X.Y in a parameter. Maybe a hyperlink to a document that explains a solution, for example: "Hey that old duration type you're passing in? You need to pass in a new version, but the old version takes the new version in one of its constructors. Here's an example ..."
I think it could "autobox" the new object for you automatically and give a warning. Then this transition would be like the Java 1.4 to Java 1.5 change (like generics, but also like auto-boxing). I understand that might be too much to ask or even not desirable. I also think it should be end-of-life'd at some point.

I don't know how to deal with the issue of reference equality tests between std and std2 types, but I don't know how often that comes up, to be honest.

It might be worth saving up a bunch of these breaking changes and coming up with a D3 that is just one breaking change of language and library that D can go off of, without breaking changes, for a long time. Perhaps it would be best to leave auto-decoding in until that version is ready.

Based on the discussion, it seems like there is not really a coherent vision and things get added here and there. That is not how popular languages are. Their releases are few and far between and they take breaking changes very seriously. People can count on the language and when they learn or build something, it is typically learned or built for good. This is not to say everything about the way popular languages are maintained is better than D. I just think the community needs to figure out a way to create stability. It doesn't mean we have to give up experimentation. Maybe there could be an experimental D++ that ports back the best features to D in spaced-out increments for the common folk. D++ would allow breaking changes and would always have features D doesn't.

<feelings>
Whoever said that D's target audience is not the people on the forum: I feel like I'm one of the people you're talking about, I just happen to be on the forum sometimes. For me, D is like a girlfriend with a borderline personality disorder. When I get real excited and try to rekindle a part of our relationship (ie try to compile something), it feels like she doesn't give a shit about me and I'm going to have to work for here love. Not exactly marriage material. Java might be ugly and not very helpful, but I know where I stand with her.

I would love to be more involved in the D community and use it for all my projects. I'd love to come up with some libraries and a microservice collection and even help develop some tools. As things stand, I hesitate to suggest using D at work, and I will shy away from committing to it in my side business, until I feel like it is stable.
</feelings>