@trusted and return ref

[via Digitalmars-d-learn]

On Thursday, 26 February 2015 at 16:25:59 UTC, Steven 
Schveighoffer wrote:
> First, malloc should be safe, in the same way new is safe.

If it is typed and do the sizeof...

> I would say THIS is somewhat correct:
>
> (() @trusted {free(count); count=null;})();
>
> This takes something that is validly safe, and keeps the safety 
> by ensuring the pointer is no longer dangling.
>
> However, we have an issue here. At any point inside the code, 
> you could do:
>
> oldcount = count;
>
> And now, there is still potentially a dangling pointer 
> somewhere. This means every place count is used must be 
> checked. In this case, all uses of count have to be re-checked 
> when the file is edited.

Yes, so count should only be accessible directly from @trusted. 
So you need to mark it "@trusted-only".

> This is a great example of why @trusted is mostly a convention 
> thing, and not an enforceable thing.

Well, it would be enforceable if you had a proper type system 
built around it.

> I agree. I think it's possible, like this:
>
> struct RCArray(E) {
> @trusted:
>
> But it doesn't help with mechanical checking -- @trusted is 
> still basically more dangerous @system code.

What you need is proper encapsulation. So that "dangerous state" 
and actions on that "dangerous state" is tied together.

And a strong type system.