Trusted Manifesto
Zach the Mystic via Digitalmars-d
digitalmars-d at puremagic.com
Tue Feb 10 07:47:12 PST 2015
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.
> This could either be kept indefinitely, or @trusted functions
> without @system blocks could slowly be deprecated and phased
> out, leading to (3).
This is a transition to the inevitable breaking change of 3. It's
the equivalent of making a DIP and then having a compiler switch
"-DIPxxx" to turn it on or off.
More information about the Digitalmars-d
mailing list