Is @trusted the wrong direction?

Alexandru Ermicioi alexandru.ermicioi at gmail.com
Sat Nov 16 20:24:59 UTC 2019


On Sunday, 10 November 2019 at 11:08:29 UTC, Paolo Invernizzi 
wrote:
> On Saturday, 9 November 2019 at 20:38:47 UTC, Alexandru 
> Ermicioi wrote:
>> On Saturday, 9 November 2019 at 16:22:05 UTC, Dominikus Dittes 
>> Scherkl wrote:
>>> I always thought trusted functions shouldn't be a thing. 
>>> Almost never a whole function need to be trusted, but only a 
>>> few lines of code. What we need instead are trusted blocks. 
>>> Those can be simulated with anonymous nested functions, but 
>>> the syntax is ugly as hell while complete trusted functions 
>>> should be forbidden.
>>
>> Had an idea how to make more nice trusted blocks:
>>
>> ```d
>> import std.stdio;
>>
>> T trusted (T)(T delegate() @system dg) @trusted {
>>    return dg();
>> }
>>
>> void main() @safe
>> {
>>     writeln("Hello D");
>>
>>     ({
>>         writeln("C ", cast(void*) 1);
>>     }).trusted;
>> }
>> ```
>>
>> looks a lot better than anonymous functions that are called 
>> right away after being defined.
>>
>> Best regards,
>> Alexandru.
>
> That's exactly the kind of stuff to avoid, in my opinion: for a 
> code reviewer point of view, this is just obfuscation, while 
> the author should write trusted code in the more pedantic and 
> clear way, to facilitate the reviewer analysis.
>
> The whole point, in trusted code, is bond to the fact that the 
> code should just be just plain easy to manually be checked.
>
> /Paolo

How is this more obfuscating than:

```d
(() @trusted => writeln("C", cast(void*) 1))();
```

In my case as reviewer, I'd find this example more hard to reason 
due to high amount of braces here.

Original solution could work in existing version of d language. 
I' m not stating that changes to facilitate more clear and less 
trusted code should not be implemented on language level given 
library solution. Trusted blocks would make sense when we're 
trying to minimize amount of such code. On this note, if trusted 
is to be added to block statements, then all annotation related 
functionality should be considered whether to add or not to block 
statements or any type os statement in general to keep annotation 
behavior uniform.

Best regards,
Alexandru.


More information about the Digitalmars-d mailing list