Is @safe still a work-in-progress?

[Jonathan M Davis]

On Friday, August 17, 2018 1:19:25 AM MDT Peter Alexander via Digitalmars-d 
wrote:
> --------
> import std.algorithm, std.stdio;
>
> @safe:
>
> auto foo() {
>    int[6] xs = [0, 1, 2, 3, 4, 5];
>    return xs[].map!(x => x);
> }
>
> void main() {
>    writeln(foo());
> }
> --------
>
> https://run.dlang.io/is/qC7HUR
>
> For me this gives:
>
> --------
> [0, 0, -2132056872, 22008, 0, 0]
> --------
>
> Which looks like its just reading arbitrary memory.
>
> I've filed https://issues.dlang.org/show_bug.cgi?id=19175
>
> My question is: what is the status of @safe? I am quite surprised
> to see such a simple case fail. Is @safe believed to be fully
> implemented (modulo bugs) and this is just an unfortunate corner
> case, or is it known work-in-progress?

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.

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, 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.

- Jonathan M Davis