Safety, undefined behavior, @safe, @trusted

[Steven Schveighoffer]

On Thu, 05 Nov 2009 14:57:48 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2009-11-05 13:33:09 -0500, Walter Bright <newshound1 at digitalmars.com>  
> said:
>
>> Safety seems more and more to be a characteristic of a function, rather  
>> than a module or command line switch. To that end, I propose two new  
>> attributes:
>>  @safe
>> @trusted
>
> Looks like a good proposal.
>
> That said, since most functions are probably going to be safe, wouldn't  
> it be better to remove @safe and replace it by its counterpart: an  
> @unsafe attribute? This would make things safe by default, which is  
> undoubtedly safer, and avoid the unnecessary clutter of @safe  
> annotations everywhere.

If unsafe means you cannot pass pointers to local variables, then half of  
tango (and other performance oriented libs which use stack allocation as  
much as possible) will fail to compile.

My vote is for unsafe as the default.  It's the least intrusive option, to  
ensure that current projects still compile.  Then let the project authors  
ensure their projects are safe one module/function at a time.

Also keep in mind that @safe annotations for a mostly safe project will be  
once at the top of each module.  They won't be "everywhere".

-Steve