Trusted Manifesto

[Zach the Mystic via Digitalmars-d]

On Tuesday, 10 February 2015 at 15:47:14 UTC, Zach the Mystic 
wrote:
> On Tuesday, 10 February 2015 at 12:27:29 UTC, Marc Schütz wrote:
>> 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.
>
> But they *have* no semantics without disallowing @system code 
> in the rest of the @trusted function.

Wait a second... you're totally right. That is a cool solution. 
The only hiccup is that it might be hard to implement in the 
compiler because of flow tracking (i.e. the error comes before 
the @system block, forcing a recheck of all preceding functions.).