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