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.
