On Thursday, 26 February 2015 at 20:56:52 UTC, Ola Fosheim
Grøstad wrote:
But it should matter, because when you mark a unit @trusted you
basically are signing off a "certificate" that says it acts
like @safe in @safe code. How can you verify anything if you
allow injections?
If you allow @system injections, you can't verify safety,
obviously. Such code must not be @trusted. That's why RCArray is
not @trusted.
You can only verify what is known when the verification took
place. After that it should be frozen so that injections of
non-verified code only goes into @safe "slots".
I don't know if it "should" work like that. I don't have a good
enough understanding of the matter to argue for or against any
one design.
[...]
Well, but @safe code is not verified either... It is inferred
@safe based on a fixed set of criterions, but not verified. To
verify you need more, and you have to start with strong typing.
The criterion being: doesn't call @system code. If that's not
enough to ensure memory-safety (given proper usage of @trusted)
then I guess the current system has failed, or the implementation
has bugs.
I don't think that the ability to break the type system (as done
in RCArray) means that @safe has failed, though. We can
forcefully break the type system in many ways. That doesn't mean
it's not sound.
I'm probably not the guy to discuss "weak" and "strong" typing
with. As I don't have a good understanding of type system theory.
