On Sun, Jan 23, 2022 at 03:24:04AM +0000, Paul Backus via Digitalmars-d-announce wrote: [...]
> The way I envision it, `std` would be the "rolling release" namespace that allows breaking changes, and if you wanted stability, you'd have to explicitly depend on `std.vN`. What we currently call `std` would be renamed to `std.v1`.

+1, this idea would work.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicest of all possible ways. -- Larry Wall

On Sunday, 23 January 2022 at 03:24:04 UTC, Paul Backus wrote:
>
> The way I envision it, `std` would be the "rolling release" namespace that allows breaking changes, and if you wanted stability, you'd have to explicitly depend on `std.vN`. What we currently call `std` would be renamed to `std.v1`.

module test;

@require("std.v2");
import std.stdio; // std is now std.v2

void main(){ }

On Sunday, 23 January 2022 at 04:12:30 UTC, H. S. Teoh wrote:
> On Sun, Jan 23, 2022 at 03:24:04AM +0000, Paul Backus via Digitalmars-d-announce wrote: [...]
>> The way I envision it, `std` would be the "rolling release" namespace that allows breaking changes, and if you wanted stability, you'd have to explicitly depend on `std.vN`. What we currently call `std` would be renamed to `std.v1`.
>
> +1, this idea would work.


I'm not so sure. Isn't the whole point of the versioning thing so you can use old things that haven't kept up with the latest?

When it was written, sure, they used import std because that's easy and of course they want the latest stuff.

Then a year later, the latest has moved on and now it is broken.

On Sunday, 23 January 2022 at 12:54:16 UTC, Adam D Ruppe wrote:
>
> I'm not so sure. Isn't the whole point of the versioning thing so you can use old things that haven't kept up with the latest?
>
> When it was written, sure, they used import std because that's easy and of course they want the latest stuff.
>
> Then a year later, the latest has moved on and now it is broken.

Unless we ship every std version with the compiler forever, things will break anyway, because someone will have to go back and add `undead` as a dependency when std.v{n-1} is removed from the official distribution.

Absolutely-no-breakage-ever is basically the C++ approach, and I have already explained why I think it's a bad idea, though I recognize that reasonable people can disagree on this point.

On Sunday, 23 January 2022 at 14:33:26 UTC, Paul Backus wrote:
> Absolutely-no-breakage-ever is basically the C++ approach, and I have already explained why I think it's a bad idea, though I recognize that reasonable people can disagree on this point.

My view is it isn't worth shipping mixed versions at all.

I'm against gratuitous breakage; it should actually provide a benefit, and I'm against dead-end breakage; it should provide a migration path.

But if there's a path to a benefit, people need to make a choice: take that path, or stop updating. Any middle ground is temporary at best anyway.

On Sunday, 23 January 2022 at 14:53:21 UTC, Adam Ruppe wrote:
> On Sunday, 23 January 2022 at 14:33:26 UTC, Paul Backus wrote:
>> Absolutely-no-breakage-ever is basically the C++ approach, and I have already explained why I think it's a bad idea, though I recognize that reasonable people can disagree on this point.
>
> My view is it isn't worth shipping mixed versions at all.
>
> I'm against gratuitous breakage; it should actually provide a benefit, and I'm against dead-end breakage; it should provide a migration path.
>
> But if there's a path to a benefit, people need to make a choice: take that path, or stop updating. Any middle ground is temporary at best anyway.

The main benefit of having multiple versions available in separate namespaces is that it allows them to coexist in the same project, which means that users can migrate their code incrementally from one to the other.

In principle you could also accomplish this with a versioned dub package and mangle-prefix [1], but progress on that initiative seems to have stalled out.

[1] https://github.com/dlang/dmd/pull/13115

On Sunday, 23 January 2022 at 15:35:17 UTC, Paul Backus wrote:
> The main benefit of having multiple versions available in separate namespaces is that it allows them to coexist in the same project, which means that users can migrate their code incrementally from one to the other.

Yeah, I know the theory, but in practice this has limited value and works best for more fine-grained things (e.g. keeping deprecated individual functions around are more helpful than whole modules).

The bigger the thing, the more likely that you'll actually introduce more bugs and compatibility issues trying to keep both versions working anyway.

> In principle you could also accomplish this with a versioned dub package and mangle-prefix [1], but progress on that initiative seems to have stalled out.

Well, that's because it was a hopeless idea from the beginning. The in-language `import` doesn't know anything about mangles, so this concept was just asking for trouble. It would work if any only if the dependencies were *completely* isolated, but even something as simple as you importing library A who uses v1.struct at the same time as library B who uses v2.struct - even if lib A and lib B's usage of that struct was entirely `private` - is liable to cause ABI crashes. Something like PIMPL can still make it work, but there's no guarantee they did that, and likely no expectation that they would in typical D code.

Anyone who has debugged extern(C) crashes after a library update knows these situations are not fun.

On 24.01.22 03:11, Mathias LANG wrote:
> Actually, the idea I had in mind is a little different.
> Because a delegate is essentially:
> ```D
> T function (T, Args..)(void* ctx, Args args)
> ```
> 
> It should be possible for the compiler to generate a call to a trampoline function that just forwards to the actual function:
> ```D
> RT _d_trampoline (FT, RT, Args..)(void* ctx, Args args)
> {
>      return (cast(FT) ctx)(args);
> }
> ```

As far as I'm aware, Walter is against that.

<https://issues.dlang.org/show_bug.cgi?id=17156#c3>:
> The compiler could, behind the curtain, generate a wrapper to do this (as you suggest), but that has negative performance implications that users could find very surprising because it would be hidden from them. I prefer the library template solution for that reason.

But that was years ago, maybe he's more open to the idea now.