D Editions

[Paolo Invernizzi]

On Friday, 20 December 2024 at 16:12:37 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> 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.

So the @safe documentation section will be "If you want memory 
safety and you want to use library from a previous editions, you 
need to review all functions marked @safe in that library"?

> If there is need, I guess we can limit calling old ``@safe`` 
> code dependent upon the arguments passed in.

You mean compiler arguments?

> However that would be a case by case solution, not something 
> that needs to be dealt with here.

The whole point in @safe is _mechanical_ check for safety, for 
_all_ code marked @safe.
Editions are breaking that, I don't understand how this is not 
needed 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.

I think that telling people that code marked @safe really means 
@trusted sometimes is a marketing disaster, but well, it's an 
opinion.

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

The whole point in @safe is to guarantee memory security with 
mechanical check. There's no other selling point for that. Holes 
are bugs, and are closed from times to times.

I think it's better to simply toss errors when compiling previous 
editions @safe functions if a hole was closed in the current, and 
not to leave the programmer clueless if there are some holes in 
the library it's using. IMHO, of course.

/P