Discussion Thread: DIP 1035-- at system Variables--Community Review Round 1
Timon Gehr
timon.gehr at gmx.ch
Wed Jun 17 16:47:33 UTC 2020
On 17.06.20 16:37, Andrei Alexandrescu wrote:
> On 6/17/20 10:30 AM, jmh530 wrote:
>> Regardless, it means that @safe is not currently safe.
>
> Affirmative. Clearly this is the problem. Opting into @system by means
> of an variable annotation that is NOT FLAGGED IF MISSING is not helping.
>
> Making @system opt-in is completely backwards.
No, it is not.
It is a tool to write correct and efficient @trusted code. @trusted code
has to ensure memory safety regardless of how @safe code behaves. The
type system and @safe checks allow @trusted code to make assumptions
about @safe code. Introducing specific features that restrict what @safe
code can do is precisely the right way to go about it and it has been
the way @trusted works from the start.
The goal of any modular analysis is to be able to at least assign blame
to any problem that ends up cropping up anyway, this is true in
particular for D's @safe/@system/@trusted and the blame always lies in
@trusted functions. Without @system variables, @trusted functions always
have to check that their invariants hold. This can range from expensive
to completely intractable, in particular if the invariants are related
to the state of memory allocators.
You are either misunderstanding @trusted or arguing in favor of
completely redesigning D's safety system and thereby destroying what
makes @trusted great. In that case we can just as well switch to the
inferior Rust `unsafe` model with unclear assumptions and guarantees and
get rid of @trusted entirely.
More information about the Digitalmars-d
mailing list