@safety of Array

[monarch_dodra via Digitalmars-d]

On Tuesday, 14 October 2014 at 17:59:43 UTC, Brad Roberts via 
Digitalmars-d wrote:
> 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.

I'm on vacation on a phone, so I'll be brief for now.

I replied what I said because I felt some arguments were leading 
to: let's make it trusted and worry about implementation layer.

I'la ignore the comment that my vision is narrow and discuss 
improvement possibilities.

The issue witH safe/unsafe split is that the functions themselves 
aren't actually unsafe, but rather their vombination: deletion is 
only unsafe *if* an escape has occurred.

The funny thing is that Array used to be sealed (specifically to 
avoid escapes) abd could have been safe. I unsealed it with 
Andrei because sealed containers come with their own problems.

To the topic at hand though, I don't think safety should dictate 
our implementations. In particular, dmd improvements can and will 
mean that something unsafe can become safe later.

The real question here is when will we implement the long 
promised scope?