@trusted and return ref

[anonymous via Digitalmars-d-learn]

On Wednesday, 25 February 2015 at 07:07:00 UTC, Ola Fosheim 
Grøstad wrote:
> On Wednesday, 25 February 2015 at 00:12:41 UTC, anonymous wrote:
[...]
> That sounds more attractive than the provided example, but the 
> right thing to do is to establish proper encapsulation. That 
> means you need a protection level that is stronger than 
> "private" that restricts "unsafe state" to a @trusted vetted 
> construct. Like unique_ptr informally does in C++.

I'm not knowledgeable enough to agree or disagree here.

>>> But why is malloc and free not considered safe by default 
>>> then?
>>
>> Well, because they aren't.
>
> So that should change?

We can't make malloc and free actually memory-safe, can we? We 
must not mark public unsafe functions @safe/@trusted.

> You mean outside RCArray, iff RCArray as a whole is manually 
> verified?  But that would surely mean that the @trusted region 
> is RCArray and neither the constructor or malloc/free?

RCArray as a whole is the actually trusted region, yes, since it 
must be manually verified that RCArray.array isn't leaked. But 
you can't mark it @trusted, because E may be unsafe.

The @trusted malloc/free dance is a mean hack to solve a problem. 
There may be other solutions that don't require breaking 
@trusted. Those may be better.

> And that assumes strong typing, which D currently does not 
> provide. Without strong typing it will be very difficult for 
> the compiler to infer anything across compilation units.

I don't follow.