June 02

I'm not the author of the proposal, but I have thoughts on how to answer these questions.

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?

You can attribute a module with the edition you are using to build. I don't know that it makes a whole lot of sense to cater to a case where you are building multiple modules with different editions by specifying command line parameters.

Other than that, there is separate compilation (which is supported via the -E switch).

>
  • 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.)

This could be via separate modules. I would anticipate the need for this to be so rare that catering to this case is also not worth the effort.

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

A good question. I would approach it from the sense that calling a function must be safe for both sides.

So if you called a function with different safety rules, and those rules reduce or compromise the safety of either the caller or the callee, it would have to be a trusted call.

Note that in terms of @safe bugs and not @safe design, one would assume the safety bugs will be fixed in the newer compiler.

>
  • 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 type annotations are defined by the language edition for the imported module. So those would be in effect.

In other words, this is not like today where you compile one module with dip1000 and another module without, and the compiler blindly assumes all are compiled the same way.

This does introduce an interesting wrinkle -- if there are differences, newer editions must define the interactions like this between editions as part of the release.

-Steve

June 02

On Thursday, 30 May 2024 at 18:31:48 UTC, Atila Neves wrote:

>

https://github.com/atilaneves/DIPs/blob/editions/editions.md

Destroy!

From the text:

>

Another compiler switch to aid transitioning that this DIP recommends is a -E switch which would function like -I for imports but would allow the user to specify what the edition should be for those imports.

It should be specified how this would work. Is it something like -E2024/usr/import/mycooldlib ?

I'm pretty sure you meant something like this, but spelling it out would make it clearer what that is for.

-Steve

June 02
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.
June 03
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.

June 03

On Monday, 3 June 2024 at 00:57:45 UTC, Adam Wilson wrote:

>

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.

This is not correct. DRT is the library side of the compiler implementation. It does not exist mostly to support phobos.

It supplies the implementation of:

  • AAs
  • Garbage Collector
  • Threads and threading primitives (needed for garbage collector support)
  • static constructors/destructors
  • TypeInfo and Object
  • string switch
  • interpolation expression sequences
  • varargs
  • exceptions and stack unwinding

These are very much tied to the compiler, and do not belong in phobos.

Incidentally, it has some pieces that are not compiler hooks or language specific pieces, but are useful to implement the druntime parts, and so they go into druntime because of the dependency direction.

It also contains system library bindings, which aren't part of the language, but are useful in both druntime and phobos.

>

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.

Tango's language runtime began as "Ares", an alternate to phobos, and was incorporated into Tango.

At the time Druntime was split out from Tango, both Tango and Phobos had the language runtime completely contained within their codebases, but the runtimes were incompatible. Druntime was an effort to separate and release a common runtime so both Tango and Phobos libraries could work together. Unfortunately, that possibility never came to fruition as druntime was D2 only, and Tango did not make the move to D2 until much much later (and by then, not many were using it).

So in fact, DRuntime is exactly an effort to serve just the compiler-needed library hooks as narrowly as possible.

Druntime needs to continue to exist as the library implementation of the language. I think it serves a very well-defined separation point, and we should not abandon that. When porting to a new platform, one only needs to port druntime (not a small task), not phobos.

-Steve

June 03
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.
June 03

On Thursday, 30 May 2024 at 18:31:48 UTC, Atila Neves wrote:

>

https://github.com/atilaneves/DIPs/blob/editions/editions.md

It looks like Editions are intended to be (Gregorian) years. If that is the case, the DIP should explicitly say that. I like the idea, but it limits us to making a new edition at most once per year. That might sound like a reasonable assumption, but it may fail occasionally, e.g. if regressions are found and fixed. It could be worth having a monthly or even a weekly resolution in Editions, i.e. make edition IDs of the form YYYY-MM or YYYY-WW where WW is the number of the week of the year (ranging between 1 and 53).

June 03

On Saturday, 1 June 2024 at 01:57:14 UTC, Steven Schveighoffer wrote:

>

On Thursday, 30 May 2024 at 18:31:48 UTC, Atila Neves wrote:

>

https://github.com/atilaneves/DIPs/blob/editions/editions.md

Destroy!

You mean module new_ 2024?

Yes.

>

I think it's pretty good. I think it should specify in the proposal what Jonathan said -- editions are meant to be source compatible. That is, all code is expected to be built with the same compiler, even if not with the same edition.

Added.

>

It should also be mentioned that only one version of druntime will be included with each compiler, and it will support all editions that compiler supports.

Also added.

June 03
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.


June 03

On Monday, 3 June 2024 at 10:49:10 UTC, Quirin Schroll wrote:

>

On Thursday, 30 May 2024 at 18:31:48 UTC, Atila Neves wrote:

>

https://github.com/atilaneves/DIPs/blob/editions/editions.md

It looks like Editions are intended to be (Gregorian) years. If that is the case, the DIP should explicitly say that. I like the idea, but it limits us to making a new edition at most once per year. That might sound like a reasonable assumption, but it may fail occasionally, e.g. if regressions are found and fixed. It could be worth having a monthly or even a weekly resolution in Editions, i.e. make edition IDs of the form YYYY-MM or YYYY-WW where WW is the number of the week of the year (ranging between 1 and 53).

I left it open in case we decided to not go with the year of release, but I'd rather that be the case. I don't think releasing editions more frequently than that is a good idea, and that bug fixes are something else entirely.