On Tuesday, 14 October 2014 at 01:47:10 UTC, Brad Roberts via
Digitalmars-d wrote:
That's why I asked the question I did. The core question isn't
about what the current implementation is or does but about
where it should end up. Should Array be usable in @safe code.
Well, I think it goes without saying that every piece of
interface that is memory safe should be @safe. Granted, for
abstract interfaces, like the range and container concepts, or
virtual functions in classes and `interface`'s, some care is
needed to determine whether or not memory safety should be a
requirement, but for concrete implementations like `Array` we
should provide the strongest guarantees possible.
To elaborate on my thinking for my previous reply: I don't know
if Array's interface in its entirety is memory safe (element
access looks murky, as was pointed out), but construction is
definitely a memory safe part of it; so yes, I think there's work
to be done here, and to that end, the safety of `RefCounted` has
to be considered first. My initial thoughts are that at least
construction of `RefCounted` should also be memory safe.
@safe vs @trusted is a red herring, it's just a matter of whether
memory safety is automatically or manually checked.
(That said, the trap here is to disregard @safe because of
current implementation deficits and just *assume* memory safety
without proper checking and applying @trusted everywhere as a
stop-gap measure. Just because it's clear that the interface is
SafeD doesn't mean the implementation is (yet), and this is what
minimized @trusted helps figure out. For example - although I'm
not sure if it technically violates SafeD - if malloc signals OOM
in Array.this, the code will steam ahead and try to emplace
elements at an offset from null. Just applying @trusted and
moving on would not catch cases like this.)
I don't think it's true that @safe is an afterthought for new
code. New generic code uses @safe unit tests to test
safe-readiness, and new non-generic code without regard for
attributes is also pointed out in review. The problem with
attributes is overwhelmingly with old code, not new code.
