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).