@safety of Array

[Jakob Ovrum via Digitalmars-d]

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.