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

[Paolo Invernizzi]

On Thursday, 26 March 2020 at 11:40:41 UTC, IGotD- wrote:
> 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.

Safe code is about preventing memory corruptions:

  - external c library can have bugs, and corrupt memory
  - the kernel can have bugs, and corrupt memory
  - the CPU can have bugs, or designs that lead to memory dumping

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.