Trusted Manifesto

[via Digitalmars-d]

On Tuesday, 10 February 2015 at 06:35:08 UTC, Zach the Mystic 
wrote:
> I never used the named @trusted function for its original 
> purpose anyway. I dont' see it as a big sacrifice, but anyway, 
> you have three choices:
>
> 1. Keep *named* @trusted functions for their original purpose, 
> continue to rely on the programmer for manual verification of 
> all @trusted code, and break no code. (status quo)
>
> 2. Give up on *named* @trusted functions as a lost cause, begin 
> using @trusted lambdas to isolate all @system code, and break 
> no code.
>
> 3. Keep named @trusted functions, introduce @system blocks to 
> isolate @system code, and break a lot of code.
>
> The way I see it, number 2 is the way to go, or at least the 
> way Andrei is headed. 3 is elegant, and if I were in charge, 
> I'd probably investigate how to make it work. 1, the status 
> quo, is the worst, because it preserves the thing of low value 
> (named @trustedness) at the expense of the thing of greatest 
> value (isolating unsafe code).
>
> I would say "destroy", but this isn't even an idea, just an 
> analysis of the tradeoffs. So, ENJOY!

As already pointed out in the other thread, there is a 
non-breaking variant of (3):

3a. Keep named @trusted functions, allow @system blocks inside 
them, but only treat those with @system blocks with the new 
semantics.

This could either be kept indefinitely, or @trusted functions 
without @system blocks could slowly be deprecated and phased out, 
leading to (3).