Safety, undefined behavior, @safe, @trusted

[grauzone]

Yigal Chripun wrote:
> On 05/11/2009 23:45, grauzone wrote:
>> Ary Borenszweig wrote:
>>> grauzone wrote:
>>>> Frank Benoit wrote:
>>>>> safe should be the default. The unsafe part should take the extra
>>>>> typing, not the other way. Make the user prefer the safe way.
>>>>
>>>> No. D is not C#.
>>>
>>> D is an unsafe language.
>>> C# is a safe language.
>>>
>>> Like that? :)
>>
>> If you mean memory safety, then yes and will probably forever be for all
>> practical uses (unless D gets implemented on a Java or .net like VM).
> 
> C# does allow memory unsafe code inside unsafe blocks. There's an alloca 
> and malloca functions for allocating on the stack.
> 
> VM is just an abstract (virtual) instruction set. You can design a safe 
> native one or an unsafe virtual one. it's all a matter of design 
> choices. there's nothing magical about a VM that makes it inherently safe.

Yes, but most VMs are designed to be memory safe for some reason, and I 
trust an instruction set designed to be memory safe more than having an 
additional "safety" feature tucked onto a complex language like D, and 
its half-assed implementation in dmd.

> IMO D should be safe by default and allow unsafe code when it is 
> appropriately marked as such, regardless of a VM.

I think most D code will have to be somewhat "unsafe" to be efficient, 
or to do stuff like binding to C libs. I already can see how code will 
be scattered with "@safe", "@trusted", etc., making that whole "safety" 
promise both a joke (theoretically) and a major PITA for the programmer 
(practically).

But it's pointless to discuss about this, because SafeD is not here yet.

> BTW, so called native code on Intel processors runs in a VM as well.
> Intel's cisc instruction set is translated to a risc like micro-ops and 
> those micro-ops are executed. the only difference is that this is done 
> in hardware by the processor.
> 

If you water down the word "VM" that much, it doesn't mean anything anymore.