D Editions

[Timon Gehr]

On 6/2/24 02:39, Steven Schveighoffer wrote:
> 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.

The whole point is not having to edit modules that were written by 
someone else just to be able to import them.

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

Editions are a module-level concept, and the default edition changes 
over time. To me it does not even seem like a serious idea to not enable 
a module-specific setting to be specified per module. We would have a 
-mv switch to virtually change the compiler-visible file paths of 
individual modules, but not a way to set their edition?

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

Exactly, a really weird UX inconsistency. We can directly import and 
build C code along D code, but somehow other D code is not afforded that 
privilege?

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

I wouldn't.

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

So old editions will keep breaking? There are currently safety bugs that 
are not being fixed specifically to avoid breakage.

>>
>> - 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

Should be in the DIP.