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.
