@system blocks and safer @trusted (ST) functions

[Bruce Carneal]

On Sunday, 25 July 2021 at 06:13:41 UTC, jfondren wrote:
> On Sunday, 25 July 2021 at 05:05:44 UTC, Bruce Carneal wrote:
>> The presence of one or more @system blocks would enable @safe 
>> checking elsewhere in the enclosing @trusted function.
>
> This has an unfortunate result: if in maintenance you edit a 
> @trusted function to remove its @system blocks, it'll quietly 
> no longer be checked as @safe.

As opposed to never being checked for @safe in legacy @trusted?  
Or always requiring manual vigilance in an "@safe" routine 
corrupted by an @trusted lambda?

More directly, IIUC, someone explicitly downgrades @safety by 
removing an @system block encapsulation from within a recently 
coded (non-legacy) @trusted function and we're supposed to second 
guess them?  They don't actually want to revert to legacy 
behavior they just happened to remove the @system block in an 
@trusted function?

I think it would be great if we can get to the point where 
warnings against legacy trusted reversions are welcome but in the 
mean time I believe the danger of not protecting against explicit 
safety degradation maintenance errors is modest when compared to 
the other issues.


> Of the current behavior, Walter's said that he doesn't want 
> @trusted blocks because they should be discouraged in @safe 
> code. With this change, we'll have exactly what he doesn't want 
> with different names: s/@trusted/@system/, s/@safe/@trusted/, 
> and the exact same behavior: @system blocks are just what 
> @trusted blocks would've been, and @trusted code with @system 
> blocks in it is just @safe code with a different name.

I think you're misreading Walter on this.  He was the one who 
recommended that I pursue this DIP at beerconf (it was just an 
idea that I'd thrown out up to that point).

>
> Instead of people accepting that @safe "isn't really @safe" in 
> the presence of @trusted blocks, and that the whole body of the 
> function has to be audited, with this change we'll have 
> s/@safe/@trusted/ blocks that aren't really @safe in the 
> presence of @system blocks, and that the whole body of the 
> function has to be audited. The "you have to audit this" 
> signifier is the same, an internal lower-protection block, and 
> all that's gained is that the function attribute's spelled 
> differently. Is this really worth it?

Definitely.  We shouldn't "accept" contradictions, cognitive 
load, manual auditing, ... unless we have no alternative.  The 
proposal opens the door to consistent nesting and naming and 
additional automated checking.  Less "unsprung weight".

> 
> I appreciate that there's a vision also to 
> @safe/@trusted/@system, but it doesn't seem to have stuck, with 
> Phobos having more than twice as many @trusted lambdas than 
> @trusted functions:
>
> ```
> phobos$ grep -rP '\W\(\) @trusted' --include '*.d'|wc -l
> 238
> phobos$ grep -rP '\w\(\) @trusted' --include '*.d'|wc -l
> 111
> ```
If the lambdas are mostly found within @safe code then these 
stats would support the proposal. Also, the @trusted functions 
could benefit from @system block upgrades.

> ...
>
> Adding a @trusted block to @safe code doesn't discard the 
> @safe/@trusted/@system vision, it just lets people follow the 
> unsafe vision that they're already following  without so many 
> complaints about how ugly the workaround is, when D's good 
> looks are one of its advantages over Rust.

I'd like to localize system code and minimize un-automated 
checking.  An @trusted lambda in an @safe function goes in the 
other direction.  It's not the two or three liner workaround 
itself that is the main problem, it's the silent expansion of 
programmer responsibility to the surrounds.

>
> This proposal also doesn't immediately discard the 
> @safe/@trusted/@system vision, but it introduces a minor 
> footgun because of a subtle conflict with that vision, and as 
> people adopt it they'll also want another --preview switch to 
> deal with the footgun, and that switch will break all current 
> @trusted code that's currently assuming no @safe checks, and so 
> there will a long deprecation cycle...

I don't see it that way.  I see a simple path to safer code.  
Your "footgun" is, in my opinion and mixing metaphors, small 
potatoes compared to the additional automated coverage evident in 
the proposal.  As I hope you'll agree, there is a huge gap 
between "this isn't a big deal, most competent programmers would 
not mess up here very often..." and "no programmers will ever 
mess up here because they can't".

>
> @trusted blocks win this. Or rather--not to be rude--but if you 
> came out and said that this DIP was just some triangulation to 
> get people to accept @trusted blocks, I would say: "good job! 
> It got me thinking!" If not, I'm sorry.

No need to be sorry at all.  If, broadly, people are happy about 
the current state of affairs and see no significant benefit to 
truth-in-naming, consistent nesting, and @safe checking within 
@trusted functions then we'll stick with what we've got.