D Editions

[Atila Neves]

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.

>>> [...]
>> 
>> 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?

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

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