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?
