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. > 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. T -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen