Trusted Manifesto

[Zach the Mystic via Digitalmars-d]

On Tuesday, 10 February 2015 at 05:18:26 UTC, Andrei Alexandrescu 
wrote:
> On 2/9/15 9:06 PM, Dicebot wrote:
>> On Tuesday, 10 February 2015 at 04:05:35 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 2/9/15 8:03 PM, Zach the Mystic wrote:
>>>> You could put the 'trusted' template right in object.d, to 
>>>> save people
>>>> the awkward burden of importing it from std.conv all the 
>>>> time. But that
>>>> would be a language change, of sorts.
>>>
>>> We won't define it. Instead we'll go with Steve's idea: () 
>>> @trusted =>
>>> expr. It's not much longer and it's a teensy bit more awkward 
>>> -
>>> exactly what the doctor prescribed. -- Andrei
>>
>> Erm. This was exactly how all those trustedFoo() nested 
>> functions have
>> appeared - we wanted to localized unsafe operations with `() 
>> @trusted
>> {}` but it wasn't properly inlined by DMD.
>
> Correct. The new rules, however, prohibit using trusted code 
> inside @safe functions. -- Andrei

There's something weird going on.

H.S. Teoh's idea for @system blocks was actually an attempt to 
reconcile Walter's stated desire to have @trusted interfaces at 
the named function level with the practical need to specify 
precisely which code was @system and allow safety checking for 
all the rest. The @system blocks were originally a way to still 
have a use for named @trusted functions, even in the presence of 
specific @system blocks. But named @trusted functions become a 
redundancy when all @system code is precisely marked. David 
Nadlinger originally pointed out almost three years ago that from 
the caller's perspective, there is *no* difference between @safe 
and @trusted. They are both effectively @safe.

The only ostensible explanation for the existence of @trusted was 
to point a programmer who had already identified problems with 
memory safety to the possible locations of the unsafe code. This 
is arguably not a good enough reason to invent a whole new 
built-in function attribute, but there it is. When you mark a 
function @safe, you are expected to make sure it's safe. It's not 
really the concern of a function attribute how you made sure it 
was safe.

@trusted lambdas are an effective way of marking unsafe code. But 
they are completely pointless, at this time, unless they are 
placed within the context a function marked (or inferred) @safe. 
For them to become the idiomatic way of marking @system code, 
there is no further purpose to any *named* @trusted function, 
ever.

To preserve the (admittedly marginal) utility of named @trusted 
functions -- that is, the opportunity for programmers using a 
library which contains only the interface function signatures and 
a binary object file to more clearly identify which of the used 
functions might be causing their memory safety problems -- while 
also allowing safety checking of all @trusted code outside 
specifically marked @system blocks, would require a breaking 
change, as indicated in the @system blocks proposal.

Avoiding the breaking change requires using @trusted lambdas in 
place of @system blocks. This nullifies the original purpose of 
named @trusted functions, as any code which effectively uses 
@trusted lambdas for their intended purpose must (implicitly or 
explicitly) be marked @safe.

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!