@safety of Array

[Dicebot 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)

There are no distinct @system parts in Array API, it is a general 
reference escaping issue with manually managed memory.

> 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)

There no issues in @safe itself, language is simply missing the 
tools to ensure no reference escaping (== scope) right now.

> 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.

There is nothing that can be done here right now as far as I see 
it. If you think otherwise PR is welcome :)