On Friday, 17 August 2018 at 14:26:07 UTC, H. S. Teoh wrote:
On Fri, Aug 17, 2018 at 01:50:32AM -0600, Jonathan M Davis via
Digitalmars-d wrote: [...]
Honestly, the reality of the matter is that @safe is probably
always going to be somewhat broken, because it's implemented
via blacklisting rather than whitelisting. Instead of @safe
only allowing stuff that's been proven to be @safe, it
disallows stuff that a programmer decided was @system.
Sigh:
https://issues.dlang.org/show_bug.cgi?id=12941
This was reported 4 years ago, but was unfortunately closed as
invalid.
It will continue to be a problem as long as @safe is
implemented via blacklisting, because every single time there's
a new language feature, there's a chance that a loophole is
introduced into @safe. And that's not counting the
combinatorial explosion of existing language features that
might lead to @safe loopholes, that we simply haven't thought
of yet. It's like allowing anyone to enter your house freely
except those few people whom you've explicitly named. You can't
possibly expect *not* to get robbed that way.
I knew there was something fundamentally wrong with @safe, but I
could never put my finger on it. Now that you and Jonathan
mention this, it becomes clear.
This makes me exceptionally sad. D is great in so many ways, but
then this taints the pool. I asked if D was ever going to be
@safe by default at DConf (https://youtu.be/HvqsUO77FGI?t=13242),
but it didn't elicit a very positive answer.
It seems D is backtracking in some ways (@nogc, -betterC), trying
to evolve it into something it wasn't originally envisioned to
be, and now we have another one to add to the list.
The bug you ran into is a pretty glaring one that arguably
should have been fixed ages ago, but given how hard it is to
prove what is and isn't @safe, there are bound to be corner
cases which have been missed. As we find them, they'll be
fixed, but who knows how many are left or whether we'll ever
actually get them all.
[...]
And that is exactly why the whole implementation of @safe is
currently rather laughable. By blacklisting rather than
whitelisting, we basically open the door wide open to loopholes
-- anything that we haven't thought of yet could potentially be
a @safe-breaking combination, and we wouldn't know until
somebody discovers and reports it.
Sadly, it seems there is little interest in reimplementing
@safe to use whitelisting instead of blacklisting.
I think there is probably some interest, though maybe not from
the ones with the position or ability to make it happen. A DIP
might be the way forward, but it seems like quite a difficult
task to turn it right-side-up at this point. I actually started
writing a DIP for this about a year ago, but I need to pick my
battles.
Mike
