D Editions
Timon Gehr
timon.gehr at gmx.ch
Mon Dec 23 18:07:45 UTC 2024
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`.
More information about the dip.ideas
mailing list