Safety, undefined behavior, @safe, @trusted

[Pelle Månsson]

Leandro Lucarella wrote:
> Michel Fortin, el  5 de noviembre a las 19:43 me escribiste:
>> On 2009-11-05 19:14:47 -0500, Walter Bright <newshound1 at digitalmars.com> said:
>>
>>> Andrei Alexandrescu wrote:
>>>> 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.
>> But if you remove bound checking, it isn't safe anymore, is it?
> 
> 100% safe doesn't exist. If you think you have it because of
> bound-checking, you are wrong.
> 
>> Sometime safety is more important than performance. If I needed
>> performance in a safe program, I'd profile and find the bottlenecks,
>> review carefully those parts of the code slowing down the program,
>> then when I trust them perfectly I'd add the @trusted attribute.
>> @trusted should remove bound checks (in release mode). @safe should
>> keep them to keep other less trustworthy pieces of of the program
>> truly safe.
> 
> What if I'm using an external library that I don't control? *That's* the
> problem for me, I want to be able to compile things I *trust* as if they
> were *trusted* :)
> 
>> That said, I'd be in favor of a compiler switch to enable/disable
>> runtime checks in release mode... perhaps "-safe" could return as
>> way to generate truly safe binaries even in release mode. This would
>> also make it pretty easy to evaluate how much impact those runtime
>> checks have on final executable (by turning on and off the compiler
>> switch).
> 
> I vote for an -unsafe (and/or -disable-bound-check). Safe should be the
> default.
> 

Doesn't safe disable features? Like taking the adress of things on the 
stack?

If I am not mistaken and this is the case, I vote against default safe. 
It's not a big problem for bigger projects that actually need safety, 
and it doesn't mess up any quick-and-dirty code.