Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[IGotD-]

On Thursday, 26 March 2020 at 11:55:32 UTC, Paolo Invernizzi 
wrote:
>
> At least, D has a tool, the trusted/safe attribute that simply 
> says:
>
> "hey folks, I can't mechanically or manually check you code, as 
> I don't have the sources, but, function A API description 
> assurers me that can't corrupt memory, so I mark its 
> declaration trusted, while function B can corrupt memory if I 
> use the wrong parameters, so I mark it system, and I will 
> provide a trusted D wrapper that will assure that the correct 
> parameters are used"
>
> At least, that's how I read the whole things.
>
> Coming back to the discussion, 'not D' externs should be system 
> by default.

Another problem is that @safe is "viral", if some function is 
@system then the whole function chain must be @system. @trusted 
was meant to bridge this gap and as I think that @trusted is an 
oxymoron, I think that we need @system blocks in order to allow a 
@system escape hatch in @safe code.

Apart from my worries that @safe by default will break more code 
than we think. The whole @safe, @trusted, @system patchwork needs 
an overhaul as well in order for @safe by default should be 
usable and convenient to work with.

The roadmap for @safe as default, I think should be.
1. Remove @trusted.
2. Implement @system blocks.
3. Then we can set @safe as default.

Right now in order for @safe to be usable, we more or less have 
to introduce a new keyword "AllowSystemInSafeCode:", otherwise 
code that use FFIs cannot use @safe at all. Alternatively we just 
make everything @system but that defeats the purpose of @safe as 
default.