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

[IGotD-]

On Thursday, 26 March 2020 at 05:14:44 UTC, Jonathan M Davis 
wrote:
>
> Making it so that all code must be either verified by the 
> compiler to be @safe or be marked by the programmer to be 
> @trusted or @system means that all code which could contain 
> memory safety issues will be segregated by @trusted or system, 
> whereas right now, you can have large swathes of code which is 
> not marked with anything and is unchecked. If the programmer is 
> not using the compiler to verify @safety and is not verifying 
> @system sections of code and marking it as @trusted, then there 
> are no compiler guarantees about memory safety in that code. 
> Sure, the programmer may have done a good enough job that there 
> are no memory safety bugs in the code (and that's far more 
> likely with D code than C/C++ code), but by making @safe the 
> default, it makes it so that none of that will fall through the 
> cracks unless the programmer explicitly tells the compiler to 
> not check.

FFI functions like extern(C) must be @system as the compiler 
cannot check this. Should extern(C) automatically mean @system? 
Well I think so because that's the only feasible possibility.

I think we are heading into the @safe, @trusted, @system 
discussion and that's where I think the problem really lies, that 
@trusted just messes things up. If @safe code can call @system 
code directly then we are good and we can us extern(C) just as 
before (with or without @system block, another discussion) If we 
have this strange "human verified" @trusted nomenclature then 
things starts because fuzzy. What is an FFI function, trusted or 
system?

I think that @trusted must go, then things start to clear up.