On Thursday, 26 February 2015 at 10:15:07 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 25 February 2015 at 22:59:01 UTC, anonymous wrote:
rule-breaking that's going on there. A public trusted_malloc
would invite the un-initiated to shoot their feet.
That's entirely social...
Sure.
A @trusted function that's not actually memory-safe is against
the definition of @trusted. Breaking that rule on a public
function is not acceptable. Breaking it locally is apparently ok
as long as the surrounding entity (RCArray) is actually
memory-safe in the end.
I'm not trying to argue that this is good. Maybe the current
system allows for a better way to solve such issues. If it
doesn't, maybe the @safe/@trusted system needs an upgrade.
[...]
If you can inject new code that is not marked @trusted
explicitly into already written code that is marked @trusted,
then the "trust type system" is broken.
The whole point of @trusted is to be able to call @system code.
It doesn't matter if that code is "injected" or not. @safe
prevents calling @system code.
[...]
It infers "@safe", but it does not provide validation.
Yup. RCArray is de-facto trusted, i.e. verified memory-safe by
the programmer. It's not compiler verified safe, even though it
ends up being labeled @safe.
