@trust is an encapsulation method, not an escape

[via Digitalmars-d]

On Saturday, 7 February 2015 at 00:31:41 UTC, H. S. Teoh wrote:
> This does not take into the account the fact that a @trusted 
> function
> may call other, non- at trusted, functions. When one of those other
> functions changes, the @trusted function necessarily needs to be
> reviewed again.
>
> However, under the current implementation, this is not done 
> because when
> the other, non- at trusted, function is modified, nobody thinks to
> re-review the @trusted function. They may not even be in the 
> same
> module. There is no mechanism in place to raise a warning flag 
> when a
> @trusted function's dependencies are modified. Thus, the proof 
> of safety
> of the @trusted function has been invalidated, but trust 
> continues to be
> conferred upon it.

So what you should ask for is a way to "sign" @trusted with a 
timestamp that indicates when it was last proven to be safe, 
e.g.: @trusted("2015-01-01T12:30:12z")

Then ask for a fine grained dependency tracking tool that can 
extract changes from git. Such a dependency tracking tool could 
be a nice stepping stone for faster compilation (sub-file-level 
recompilation). So there is synergies in this.

The proposal to confuse @trusted/@safe with requiring @system 
within @trusted it not a language issue. It is a process issue 
and can be done with lint-like tooling.

Keep @trusted/@safe/@system simple. Enough convoluted semantics 
in D already.