User defined safety?

[Lutger Blijdestijn]

I wonder if anybody has brought up the idea of using or expanding the SafeD 
features to cover a user-defined kind of safety? Right now, @safe means 
memory safe and it is defined by the language. However, there are many kinds 
of safety that benefit from being layered in a manner similar to how 
safe/trusted/system works.

A web application for example might want to restrict raw sql access in one 
layer, where care is taken to avoid injection attacks. The rest of the 
application trusts only this layer and is forbidden from accessing the sql 
drivers directly.

A security audit script can grep for such forbidden use of sql, thus 
enforcing a 'provable' safe use of sql (with the liberal use of the word 
provable). In D it could be possible to enforce this layered design by the 
compiler. It is possible right now by an application programmer through the 
(ab)use of safe/trusted/system, by lumping memory and sql-injection safety 
together, though this has some serious drawbacks. What do you think of this, 
is it a good or bad use of these features?

Going further, SafeD could be expanded by allowing user defined security 
labels as parameters of safe/trusted/system. For example, the user could 
define @system(SQL) and @trusted(SQL) as well as @system(SMTP) and 
@trusted(SMTP). @safe code can use the @trusted sql and smtp components, but 
not @system. In this model, @trusted(SMTP) is only allowed to call 
@system(SMTP) and not @system(SQL).