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.