On 11/9/19 11:22 AM, 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.

Yeah, it would be nicer. But the sad part is that a @safe function with @trusted pieces STILL has to be completely manually verified. Because a @trusted lambda can muck with the guarantees of the @safe parts inside the lambda. In essence, a function boundary is the correct place, because that's where the safety guarantees are defined.

What a @safe function with @trusted parts DOES do, is help the focus of the review. You can look at the trusted lambda and reason about what possibly safety problems could arise from it, then check all the safe code to see if those cases happen.

I'd still be in favor of a less verbose trusted block syntax. Not only for the brevity, but also because relying on the optimizer/inliner to properly write the code seems like a code smell.

-Steve

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.

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

On Sunday, 17 November 2019 at 14:37:16 UTC, Paolo Invernizzi wrote:

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

I fully agree that a library wrapper around @trusted lambdas are a bad idea. They neither provide the desired short and readable syntax nor do they solve the three-state enum around safety.

But the small compiler-change proposed by anon5886 is really very nice.

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

> 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.
Editors can highlight @trusted blocks heavily and ugly, so you will automatically try to keep those sections as small as possible.
And no newbie is irritated anymore what this third thing between safe and system should be.

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.