@trusted and return ref

[via Digitalmars-d-learn]

On Wednesday, 25 February 2015 at 18:58:13 UTC, anonymous wrote:
> We can't make malloc and free actually memory-safe, can we? We 
> must not mark public unsafe functions @safe/@trusted.

My point was that there is no conceptual difference between 
having a named function trusted_malloc!int() and trusted_free() 
and wrapping them up individually unnamed.

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

But the semantic analysis should verify that code isn't injected 
unless it is also @trusted?

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

C is not strongly typed, and neither is D. That means there are 
holes in the type system.