Adam Wilson kirjoitti 1.6.2024 klo 7.31:
>
> As we dig into Phobos 3 this is something that I’ve started to think
> about more. Realistically, I think the concept of entirely freezing DRT
> is simply not practical in the long term. Phobos is going to expand, and
> DRT will need to expand with it. I can only see pain and ruination if we
> box ourselves into freezing DRT.
>
> [snip]
Yes, I agree this is something we need to decide. I also agree that locking DRuntime API isn't a good idea.

But, I think it should be updated with the compiler, not with Phobos. DRuntime is essentially language API that is called without special langauge syntax.

I think what edition DRuntime uses internally is it's own implementation detail. We should design it so it works with all editions on the client side - just like any widely used library will want to do.

There will probably be times when we want to change behaviour based on what edition client code uses. I suggest adding a special token for that, `__EDITION__`. A DRuntime function, (or any D function, really), can use that as a default parameter to figure out what edition the client is using, just like `__FILE__` and `__LINE__` can be used as default parameters for debugging functions. We can use that trick to deprecate old functions.

Given any particular edition X, a DRuntime function should be supported indefinitely, but when changing editions in the client module, DRuntime calls may also need revision. This also lets code to call DRuntime functions from other editions if they really want to, which I see as a good thing. This also means Phobos will have easy time using it, since it can pick it's own edition for it's modules and DRuntime will support that to matter the compiler version.

On Sunday, 2 June 2024 at 09:38:54 UTC, Dukc wrote:
> Yes, I agree this is something we need to decide. I also agree that locking DRuntime API isn't a good idea.
>
> But, I think it should be updated with the compiler, not with Phobos. DRuntime is essentially language API that is called without special langauge syntax.

I'm writing a longer post on this subject. But the TL;DR is that this view is factually incorrect and is based on an misunderstanding of what DRT is to the ecosystem. Only a tiny fraction of DRT today deals with the compiler (as an API for language). The vast majority of DRT is providing system resources to Phobos. Given that the library-system interface is only going to continue to grow, logic would dictate that tying DRT to the library is the only practical choice. Tying DRT to the compiler forces Phobos to wait for the latest edition to use the latest DRT, which makes no sense given that the vast majority of the work is on the system-interface components and not the compiler-interface.

Fun historical note, DRT began as a system-interface library for Tango and only later was it used as a convenient place to put compiler hooks. The commonly held view that DRT primarily exists to serve the compiler is a fascinating confirmation that we've moved past the Tango/Phobos split though.

> I think what edition DRuntime uses internally is it's own implementation detail. We should design it so it works with all editions on the client side - just like any widely used library will want to do.

Technically yes, but in practice, because we can mix-match editions, DRT will always need to support the latest edition. From a practical standpoint you always need to be using the most recent edition that the user code is compiled to, and since Editions are being built as "latest edition by default" that means that by default the latest Runtime and Libraries are going to be used. So might as well just support the latest.

> There will probably be times when we want to change behaviour based on what edition client code uses. I suggest adding a special token for that, `__EDITION__`. A DRuntime function, (or any D function, really), can use that as a default parameter to figure out what edition the client is using, just like `__FILE__` and `__LINE__` can be used as default parameters for debugging functions. We can use that trick to deprecate old functions.

IMO, special tokens are always a horrible solution. In this case because it does not fully solve any of the three ABI scenarios I listed. You still have to follow the Rename rules the moment you need to change the parameter list in any way. All the special token does is allow you to branch on different editions when the code has internal changes, so it solves arguably the least important subset of Edition related problems. Furthermore, once you are forced to change the parameter list you've now create a small number of methods that each contain an opaque number of Edition implementations, which means the consumer now has to mentally juggle which API contains which edition they need.

> Given any particular edition X, a DRuntime function should be supported indefinitely, but when changing editions in the client module, DRuntime calls may also need revision. This also lets code to call DRuntime functions from other editions if they really want to, which I see as a good thing. This also means Phobos will have easy time using it, since it can pick it's own edition for it's modules and DRuntime will support that to matter the compiler version.

Agreed. When designing for the long-term there are very few practical ways to do it, which is why I laid out the process that I did. It's a well established way of handling this problem. We know it works.

I've gone through this with Adam already.

What he is seeing is related to interdependencies of different aspects to the ecosystem and he is very much correct about this. I saw this myself many years ago.

However the terminology and language he uses is different than what we are using so it may appear he is talking wild when in fact it is a matter of recognizing dependencies and putting things in a better place.

Ultimately we have a ton of technical debt, the entire TypeInfo hierarchy doesn't have a purpose for example. The GC certainly doesn't need it, it could work 100% with just a by-value struct.

Which leads to the interesting discussion of how to handle its removal wrt. editions. My general conclusion there is to use shims that are do-nothing long term but keep code compiling and then deprecate in like 10 years.

On Saturday, 1 June 2024 at 21:14:38 UTC, Timon Gehr wrote:
> On 5/30/24 20:31, Atila Neves wrote:
>> https://github.com/atilaneves/DIPs/blob/editions/editions.md
>> 
>> Destroy
> - How do you compile different modules with different editions on the same command line?

If they all have module declarations, it's handled there, otherwise I hadn't thought of that. Do you think that will be common? I'm not sure it will be.

> - How would a library expose different interfaces to importers that use different editions? (This may be required because different editions allow different interface designs and guarantees, or have a different user-accessible druntime interface and e.g. druntime types are in the library API.)

Good question. I guess we'll need some kind of `version(Edition2024)`.

> - How does a newer edition with less `@safe` bugs treat `@safe` code from an older edition that has more memory safety holes?

I think I'd need a concrete example.

> - How do function interfaces work when some type annotations exist in only either the language edition of the caller or the language edition of the callee? E.g. think DIP1000 is in one edition but not in another.

The semantics of the edition of the callee apply.