D Editions
Paolo Invernizzi
paolo.invernizzi at gmail.com
Fri Dec 20 17:20:35 UTC 2024
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
More information about the dip.ideas
mailing list