Safety, undefined behavior, @safe, @trusted

[Andrei Alexandrescu]

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> 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?
> 
> You're right from a theoretical perspective, but not from a practical 
> one. People ought to be able to flip on 'safe' without large performance 
> penalties.
> 
> If it came with inescapable large performance penalties, then it'll get 
> a bad rap and people will be reluctant to use it, defeating its purpose.

This is a showstopper.

What kind of reputation do you think D would achieve if "safe" code has 
buffer overrun attacks?

A function that wants to rely on hand-made verification in lieu of 
bounds checks may go with @trusted. There is absolutely no way a @safe 
function could allow buffer overruns in D, ever.


Andrei