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.
