Is @safe still a work-in-progress?

[Walter Bright]

On 8/17/2018 12:50 AM, Jonathan M Davis wrote:
 > That particular bug is a duplicate of
 > https://issues.dlang.org/show_bug.cgi?id=8838, which was closed as fixed
 > based on the fact that -dip1000 fixes the problem by treating marking the
 > slice of a static array with scope. It's still quite broken without -dip1000
 > though.

D will never be @safe until -dip1000 is the default. However, I cannot get any 
traction with improving this:

https://github.com/dlang/dmd/pull/8504

blocks progress on getting Phobos to compile with -dip1000, and nobody will help 
me with it.


 > 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. The bug you
 > ran into is a pretty glaring one that arguably should have been fixed ages
 > ago,

It was fixed with -dip1000 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.

The whitelisting idea has come up before. I see it, though, as a way to avoid 
dealing with the issues as nobody is willing to do any work at all on this 
approach. Furthermore, I see no evidence that whitelisting will produce superior 
results.

On the other hand, I see plenty of evidence that @safe bugs that are found and 
posted to bugzilla get fixed.

If people want to see @safe be watertight,

1. post any problems to bugzilla, and tag them with the 'safe' keyword.

2. investigate solutions to any issues tagged with 'safe' keyword.

3. review/approve PR 8504.