Is @trusted the wrong direction?

[Paolo Invernizzi]

On Saturday, 16 November 2019 at 20:24:59 UTC, Alexandru Ermicioi 
wrote:
> 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.

I remember a discussion some time ago about the overusing of 
@trusted-as-a-super-thin-wrapper around @sytem calls, made by 
Andrei and Walter over some parts of Phobos, and that proposed 
work just walks towards that same direction.

The point is, I'm against @trusted blocks, as I think it's more 
clear to have a fundamental minimal aggregate of code 
functionality: the function, as it's right now, especially for a 
reviewer.

The function has everything needed, documentation, contracts, 
everything is optimised, to clearly explain what should be the 
input, the output, and what's the intention of the code inside of 
if.

The mere fact that a reviewer must pay attention not only to 
@trusted, but 'trusted' as a template, or why not '__trusted', or 
'this_is_trusted', and so on, it's just opening a can of worms 
when you review unfamiliar codebase. With a lesser impact, I 
think that this also holds with an implementation on language 
level.

I underline, that are only personal opinions, I understand your 
point around the issue.

> 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.

The difference is that pure, nothrow or nogc are mechanically 
checked, so if attributes are scattered around the codebase, also 
inside code blocks, there's not an impact: the compiler happily 
digests them.

That's not true for trusted ...

The introduction of pure, nothrow or nogc blocks can be an 
interesting option to investigate, especially for @nogc, but I 
guess that the latter is linked to the GC vs allocator work (DIP 
1025, to be clear).

Cheers,
Paolo