@trusted and return ref

[via Digitalmars-d-learn]

On Wednesday, 25 February 2015 at 00:12:41 UTC, anonymous wrote:
> If the whole function was @trusted, the compiler wouldn't catch 
> other safety violations that are not related to malloc/free.

You don't need to. In C++ you use a separate "@trusted" 
data-structure for capturing ownership, aka unique_ptr (which 
provides a type related to linear typing).

> The downside is that @safe on that function then doesn't mean 
> "compiler verified memory-safe" anymore. Instead it means 
> "compiler assisted @trusted".

Not only on that function, on the whole data structure? You no 
longer have a scope for what code is considered dangerous.


> There's also the other way around: Mark the function as 
> @trusted and throw ()@safe{...}() covers over the 
> non-problematic parts. This doesn't work when a template 
> parameter affects the safety, though.

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


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

So that should change?


> The goal is to have human verified, compiler recognized 
> memory-safety, when E allows for it.
>
> You can't:
> * mark nothing @safe/@trusted, because malloc/free are not safe;
> * mark the methods @trusted, because E may be unsafe.
>
> @trusted malloc/free is a hack, but it allows the compiler to 
> infer @safe iff E is safe.

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?

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.