@trusted and return ref

[anonymous via Digitalmars-d-learn]

On Thursday, 26 February 2015 at 10:15:07 UTC, Ola Fosheim 
Grøstad wrote:
> On Wednesday, 25 February 2015 at 22:59:01 UTC, anonymous wrote:
>> rule-breaking that's going on there. A public trusted_malloc 
>> would invite the un-initiated to shoot their feet.
>
> That's entirely social...

Sure.

A @trusted function that's not actually memory-safe is against 
the definition of @trusted. Breaking that rule on a public 
function is not acceptable. Breaking it locally is apparently ok 
as long as the surrounding entity (RCArray) is actually 
memory-safe in the end.

I'm not trying to argue that this is good. Maybe the current 
system allows for a better way to solve such issues. If it 
doesn't, maybe the @safe/@trusted system needs an upgrade.

[...]
> If you can inject new code that is not marked @trusted 
> explicitly into already written code that is marked @trusted, 
> then the "trust type system" is broken.

The whole point of @trusted is to be able to call @system code. 
It doesn't matter if that code is "injected" or not. @safe 
prevents calling @system code.

[...]
> It infers "@safe", but it does not provide validation.

Yup. RCArray is de-facto trusted, i.e. verified memory-safe by 
the programmer. It's not compiler verified safe, even though it 
ends up being labeled @safe.