Is @safe still a work-in-progress?

[Mike Franklin]

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