Safety, undefined behavior, @safe, @trusted

[Don]

Andrei Alexandrescu wrote:
> 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.

I agree if the flag is called "-release". But if the "disable bounds 
checking"  flag is renamed to -unsafe or similar, I can't see any impact 
on reputation.