November 06, 2009Re: Safety, undefined behavior, @safe, @trusted
Posted in reply to Andrei Alexandrescu
Hello Andrei, > Walter Bright wrote: > >> Jason House wrote: >> >>> I posted in the other thread how casting to immutable/shared can be >>> just as bad. A leaked reference prior to casting to immutable/shared >>> is in effect the same as casting away shared. No matter how you mix >>> thread local and shared, or mutable and immutable, you still have >>> the same undefined behavior >>> >> Not undefined, it's just that the compiler can't prove it's defined >> behavior. Hence, such code would go into a trusted function. >> > Are we in agreement that @safe functions have bounds checking on > regardless of -release? > > Andrei > I think there are two cases: User would want max performance from a some library, but he does not care about performance. User should have the right to override intentions of library writer, making his code less safe, to achieve speed. Compiler flag -unsafe (or -unsafe-no-bounds-checking) should do this. The user will know that he is *overriding* the original safety to lower level. Also, when a library writer wants his code to appeal and be usable to most users, he should mark it @safe or @trusted. But in situation, when he knows that safe code would be always bounds-checked (there is no -unsafe compiler switch), he may rather mark his code @trusted, even if it would be safe, in order to appeal to user that don't want slow (bounds-checked) library. If the library writer knows that users can override safety (bounds-checking), he would not hesitate to use @safe where appropriate. the -unsafe-no-bounds-checking flag is essential for properly working of safeness in D.