D Editions

[Timon Gehr]

On 6/3/24 18:05, Atila Neves wrote:
> 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.
> ...

A lot of code will be written against the default edition and then 
abandoned at some point.

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

Something like that, but `version` only includes one of the symbols, 
while here we would need to compile all of them.


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

E.g., there are bugs that allow you to mutate through `const` pointers. 
Some of them may not be fixed in edition 2024 because the fix would 
break code. However, in edition 2025 the bugs are fixed. Now edition 
2025 calls into a function from edition 2024 that violates memory safety 
by modifying a const pointer. All involved code is `@safe`, yet memory 
safety is violated and this hole can never be fixed if edition 2025 can 
just call into edition 2024.


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

This might not work because annotations in a parameter list may require 
caller-side guarantees in order to be checked.