@safety of Array

[Brad Roberts via Digitalmars-d]

On 10/14/2014 3:49 AM, monarch_dodra via Digitalmars-d wrote:

> You say I'm focused on impl, but @safe *is* an implementation
> certification.
>
> I'm not derailing the thread or talking about process. If Array can't be
> certified memory safe, then it can't be marked as @safe. That's really
> all there is to it.

Sorry, the request to not derail was for future posts to the thread, not 
a reaction to your comment.  I was/am worried that the "more and more 
code being created" comment would spiral the discussion sideways.

Your response wasn't making any statements of what should happen but 
rather why it can't based on the current state.  Useful, but still 
irrelevant to the Should question.  Unless you were saying that it 
shouldn't become usable due to that part of the api.  To that I'd 
respond that your thinking is too narrow in scope or too black and white.

As to the rest, once we decide if Array should be usable in the @safe 
subset of the language, then we can start to make choices about how to 
achieve that.  Some obvious choices:

1) remove the parts that aren't (unlikely to be a good choice)

2) partition the api into parts that are and parts that aren't (only 
some parts get the @safe attribute, maybe some gets @trusted)

3) improve the implementation of @safe to cover all the parts that can't 
right now (likely to result in significant delay before any useful 
progress is made)

4) force the parts that aren't anyway (probably violates the basic 
precepts of @safety but including for the sake of completeness)

5) ?

6) some combination of the above

My personal thinking is that #2 is the way to go in the short term as 
long as a reasonably large subset of the functionality can be made 
usable (right now we can't even construct one).  With a likely very 
strategic sprinkling of @trusted where absolutely necessary.  As #3 
progresses on it's own merits, the set that falls into #2 might expand.