D Editions

[Timon Gehr]

On 12/19/24 17:52, Atila Neves wrote:
> On Thursday, 6 June 2024 at 15:47:50 UTC, Timon Gehr wrote:
>> On 6/3/24 18:05, Atila Neves wrote:
>>> On Saturday, 1 June 2024 at 21:14:38 UTC, Timon Gehr wrote:
>>>> [...]
>>>
>>> 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.
> 
> We can add a compiler switch similar to `-mv` in the future if needed. 
> I'm not sure it needs to go in the DIP.
> ...

Maybe not, though I anticipate I will need this.

>>>> [...]
>>>
>>> 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.
> 
> Why do we need to compile all of them? Do we need something like 
> `__traits(callerEdition)` maybe?
> ...

It may not be known at library compile time what edition the user will 
be using, and there may be multiple different users on different editions.

>>>> [...]
>>>
>>> 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.
> 
> I think we will just have to live with this and encourage people to 
> upgrade to the newer edition.
> ...

Maybe, though it does invalidate memory safety guarantees. Another way 
to deal with it is to require something like `@trusted import` for such 
modules or to otherwise treat all `@safe` imports from that module as 
`@system`.

>>>> [...]
>>>
>>> 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.
> 
> Maybe there will be changes we won't be able to make.
> 

Maybe, though I think one thing that will often work is to make such 
calls `@system`.