Safety, undefined behavior, @safe, @trusted

[Michal Minich]

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.