Is @trusted the wrong direction?

[Paolo Invernizzi]

On Sunday, 17 November 2019 at 16:41:16 UTC, Dominikus Dittes 
Scherkl wrote:
> On Sunday, 17 November 2019 at 14:37:16 UTC, Paolo Invernizzi 
> wrote:
>
>> 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.
>
> This will not change. The function keeps it info: it is @safe, 
> so it has to provide a memory-safe interface.

It's "safe" because a human inspected it and I'm trusting the 
human. That's a huge difference from "safe" because it was 
certified by the compiler automatically.

I think that the internal trusted block simply hide this 
information, the caller need to check the body.

> It's only sightly more obvious to the reviewer, because he 
> doesn't have to remember that @trusted is only and alias for 
> @safe, from the caller point of view.

Well, I hope that a reviewer checking @trusted code knows the 
difference very well

:-P

>> 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.
>
> But this is exactly NOT he case. If he reviews a function that 
> is marked @safe his alarm bells only need to ring, if the 
> function contains a @trusted block. Nothing else. There are no 
> trusted templates or macros or other __-stuff anymore.
>
> But of course the whole function must be treated with care, if 
> it contains a @trusted block, no change there. But the parts 
> that need to be trusted should be as sparse as possible, and a 
> short and clear syntax helps in doing this.

I think documentation, contract and a clear encapsulation in a 
function help the reviewer more ... but that's only my opinion, 
not a fact.

> Editors can highlight @trusted blocks heavily and ugly, so you 
> will automatically try to keep those sections as small as 
> possible.

I don't see anything ugly in @trusted, it's simply a necessary 
form to connect safe to system.

> And no newbie is irritated anymore what this third thing 
> between safe and system should be.

I've not seen any complain on that in learn forum, but maybe you 
have a better visibility than me on that.

I find the safe-trusted-system triade very intuitive, for sure 
more than other recently proposed D features.

But again, I understand your point of trying to minimise the 
amount of trusted code around.