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