@trusted and return ref

[anonymous via Digitalmars-d-learn]

On Wednesday, 25 February 2015 at 22:16:14 UTC, Ola Fosheim 
Grøstad wrote:
> 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.

An ad-hoc declared @trusted malloc is just as unsafe as a public 
one, of course. But there's a difference in exposure. People 
working on RCArray are supposed to know about the rule-breaking 
that's going on there. A public trusted_malloc would invite the 
un-initiated to shoot their feet.

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

You mean the compiler should enforce E to be @safe/@trusted? That 
wouldn't happen with an @trusted RCArray, because @trusted code 
may call @system code.

It would be done with an @safe RCArray. But I guess that's deemed 
too limiting. RCArray is supposed to work with unsafe E types, 
too.

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

I'm a bit lost. What I meant was that the compiler infers @safe 
for methods of templated structs when they don't call any @system 
code.

Here: RCArray's this/~this are inferred @safe iff E's 
__postblit/__dtor are @safe/@trusted.

This is how it works right now, regardless of any holes in the 
type system.