D Editions

[Steven Schveighoffer]

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