https://issues.dlang.org/show_bug.cgi?id=22013
Stanislav Blinov <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Stanislav Blinov <[email protected]> --- Adding @safe: at the top stops compilation in its tracks as the ctor and dtor for RefCounted get inferred @system. With 2.098 and -dip1000 also an attempt to escape a local into RefCounted's ctor __is__ detected. Escaping a local static array in @safe doesn't seem possible, so it would seem this issue is no longer valid? However, as pertains to the goals of pull request mentioned above, even if the aforementioned problems in RefCounted's implementation are fixed, ref counted slices (even in disguise) can't possibly have their destructor @safe, as long as we can do this: void test() @safe { auto slice = makeSomeKindOfRefCountedSlice!int(10); int[] local = slice.payload.data; static assert(!__traits(compiles, &slice)); // scope static assert(!__traits(compiles, &local)); // scope slice = slice.init; // drop ref count to 0 and deallocate local[1] = 32; // use after free in @safe function } It almost looks like we need a way to define functions that return only temporaries (so that the line `int[] local = slice.payload.data` above doesn't compile). Until we can do that in some form, any @safe destructor of such ref-counted slice could only be safe by convention (i.e. what's the point then?). --
