safety model in D

[Andrei Alexandrescu]

Jesse Phillips wrote:
> On Tue, 03 Nov 2009 17:55:15 -0600, Andrei Alexandrescu wrote:
> 
>> There's a lot more, but there are a few useful subspaces. One is, if an
>> entire application only uses module(safe) that means there is no memory
>> error in that application, ever.
>>
>> Andrei
> 
> Does that mean that a module that uses a "trusted" module must also be 
> marked as "trusted?" I would see this as pointless since system modules 
> are likely to be used in safe code a lot.

Same here.

> I think the only real option is to have the importer decide if it is 
> trusted.

That can't work. I can't say that stdc.stdlib is trusted no matter how 
hard I try. I mean free is there!

> I don't see a reasonable way to have third party certification. 
> It is between the library writer and application developer. Since the 
> library writer's goal should be to have a system module that is safe, he 
> would likely want to mark it as trusted. This would leave "system" unused 
> because everyone wants to be safe.

Certain modules definitely can't aspire to be trusted. But for example 
std.stdio can claim to be trusted because, in spite of using untrusted 
stuff like FILE* and fclose, they are encapsulated in a way that makes 
it impossible for a safe client to engender memory errors.

> In conclusion, here is a chunk of possible import options. I vote for the 
> top two.
> 
> import(system) std.stdio;
> system import std.stdio;
> trusted import std.stdio;
> import(trusted) std.stdio;
> import("This is a system module and I know that it is potentially unsafe, 
> but I still want to use it in my safe code") std.stdio;

Specifying a clause with import crossed my mind too, it's definitely 
something to keep in mind.


Andrei