Safety, undefined behavior, @safe, @trusted

[Yigal Chripun]

On 07/11/2009 11:53, Don wrote:
> Walter Bright wrote:
>> grauzone wrote:
>>> 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).
>>
>> A VM is neither necessary nor sufficient to make a language memory
>> safe. It's all in the semantics of the language.
>
> In practice, the big disadvantage which D has is that it can make calls
> to C libraries which are not necessarily memory safe -- and this is an
> important feature of the language. Dealing with the external,
> uncheckable libraries is always going to be a weak point. Both Java and
> .net have mitigated this by rewriting a fair chunk of an OS in their
> libraries. That's probably never going to happen for D.


Sun pretty much implemented a full OS inside the JVM. At least their RT 
offering contains a scheduler in order to provide guaranties regarding 
collection time.

In .Net land, MS uses .net to implement parts of their OS so no surprise 
there that those OS APIs are available to .net code. I wouldn't say that 
it's part of their libraries but rather parts of the OS itself.

What parts of the OS are still missing in D's standard library? Isn't 
tango/phobos already provide all the common parts like i/o and 
networking and a few other major libs provide bindings/implementation 
for UI, 3d & multimedia, db bindings, etc?

I think that the big disadvantage you claim D has isn't that big and it 
is well underway to go away compared to .net/java.
Both Java and .net also provide ways to use unsafe C code (e.g. JNI, 
COM), It just a matter of what's the default, what's easier to do and 
what can be done without choosing the unsafe option. I think that D 
isn't that far off behind and could and should catch up.