@trusted and return ref

[anonymous via Digitalmars-d-learn]

On Thursday, 26 February 2015 at 20:56:52 UTC, Ola Fosheim 
Grøstad wrote:
> But it should matter, because when you mark a unit @trusted you 
> basically are signing off a "certificate" that says it acts 
> like @safe in @safe code. How can you verify anything if you 
> allow injections?

If you allow @system injections, you can't verify safety, 
obviously. Such code must not be @trusted. That's why RCArray is 
not @trusted.

> You can only verify what is known when the verification took 
> place. After that it should be frozen so that injections of 
> non-verified code only goes into @safe "slots".

I don't know if it "should" work like that. I don't have a good 
enough understanding of the matter to argue for or against any 
one design.

[...]
> Well, but @safe code is not verified either... It is inferred 
> @safe based on a fixed set of criterions, but not verified. To 
> verify you need more, and you have to start with strong typing.

The criterion being: doesn't call @system code. If that's not 
enough to ensure memory-safety (given proper usage of @trusted) 
then I guess the current system has failed, or the implementation 
has bugs.

I don't think that the ability to break the type system (as done 
in RCArray) means that @safe has failed, though. We can 
forcefully break the type system in many ways. That doesn't mean 
it's not sound.

I'm probably not the guy to discuss "weak" and "strong" typing 
with. As I don't have a good understanding of type system theory.