DIP1028 - Rationale for accepting as is

[Johannes Loher]

On Monday, 25 May 2020 at 11:40:46 UTC, Johannes T wrote:
> On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote:
>> [..]
>> But with the DIP in its current form, we make @safe lose its 
>> meaning and power, which is much worse in my opinion.
>> [..]
>
> The alternative, not making extern @safe, would result in more 
> untrustworthy @trusted code we have to worry about. It's a 
> vicious circle.
> I try to relax my view on extern annotations. They are @system. 
> We *should* go ahead and diligently mark with @trusted. From 
> experience, it doesn't normally happen.
> I don't like @safe extern, but it seems like the lesser evil. 
> Walter got a lot of flak. I tried to retrace his thoughts and 
> see the merits.

 From my perspective it is really simple: Either we have a strict 
@safety system (with exactly one escape hatch) or we don't. At 
the moment we don't because you can have @safe extern(C) 
declarations but with this DIP it becomes even worse as it is 
more likely that @safe promises are broken without anybody 
noticing.

If you and more importantly Walter and Atila really think this is 
the lesser evil and that it is worth dropping the strict @safety 
system with exactly one controlled escape hatch for this, then we 
also need to clarify what @safe means after that. We can 
definitely not claim that it means machine verified except for 
@trusted because extern(C) functions are another escape hatch. 
The question has been asked in this thread a few times already: 
What does @safe actually mean? How to „sell“ / „advertise“ it?