D Editions

[Richard (Rikki) Andrew Cattermole]

On 21/12/2024 2:43 AM, Paolo Invernizzi wrote:
> On Thursday, 19 December 2024 at 16:52:35 UTC, Atila Neves wrote:
>> On Thursday, 6 June 2024 at 15:47:50 UTC, Timon Gehr wrote:
> 
>>> 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.
> 
> So using a library from a previous edition *could* invalidate memory 
> safety guarantees, and nothing can be done?
> 
> This is (again) a marketing disaster ...

The solution I came up with that works for both escape analysis and type 
state analysis, is to treat the old ``@safe`` code as ``@trusted``, so 
it all gets inferred to make guarantees in new edition, but without any 
of the errors to allow for old behavior to continue.

If there is need, I guess we can limit calling old ``@safe`` code 
dependent upon the arguments passed in. However that would be a case by 
case solution, not something that needs to be dealt with here.

So I don't see how this is a marketing disaster, it can be dealt with if 
needed and where it can't, it is your responsibility like it is with 
``@trusted`` in newest edition.

After all, ``@safe`` does not guarantee program security, it is going to 
have holes in it and some things are left to you.