On Friday, 6 February 2015 at 06:25:06 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 8:24 PM, Dicebot wrote:
I referred to this fact with a comment "it is better to make no
promises than to make one and break it". Simply dealing with
unsafe language is something I got used to - all crashes and
weird think become expected. It is totally different from
seeing
a memory corruption with @safe - "hey, you lied to me, it is
not
safe!". Because of that amount of responsibility reviewing
@trusted is much higher than reviewing @system. I can do the
latter because I don't pretend review to be perfect. With
@trusted pressure is much harder.
Oh I understand. The notion of calibration comes to mind.
I'd like D to provide the following guarantee: If I corrupt my
memory using @safe code, the error must be in code marked
@trusted / @system, either because the do not provide a @safe
interface or because they are buggy.
We'll never provide a stronger guarantee as long as we allow to
escape @safe-ty, just like we'll never be able to guarantee that
a T is a valid T as long as we allow casts.
I think the guarantee is worth the effort, though.
