@system blocks and safer @trusted (ST) functions
bcarneal at gmail.com
Sun Jul 25 12:56:33 UTC 2021
On Sunday, 25 July 2021 at 09:04:17 UTC, jfondren wrote:
> On Sunday, 25 July 2021 at 08:16:41 UTC, Bruce Carneal wrote:
>>> 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).
> I think it's a fair reading of
> From "With this change"&c that's all in my voice.
It may well have been a fair reading of the past. I reported on
the present (yesterday).
>> I'd like to localize system code and minimize un-automated
>> checking. An @trusted lambda in an @safe function goes in the
>> other direction.
> Presently, when you write a function that you want to be mostly
> @safe but that needs to break those restrictions in part, you
> call it @safe and you put the violation in a @trusted lambda.
> With your proposal, when you write a function that you want to
> be mostly @safe but that needs to break those restrictions in
> part, you call it @trusted and you put the violation in a
> @system block.
> These seem to me to be so identical that I don't see how they
> can be moving in opposite directions. You need to audit the
> same amount of code, and you find that code with the same
> exertion of effort.
They are similar in some regards, but if trusted lambdas are the
only practical option for this type of code going forward, then
@safe will require manual checking in perpetuity.
I'm not saying mitigating tooling or procedures to cover this can
not be devised/employed. I am saying that there is a qualitative
difference between "the compiler asserts" and "my
super-duper-xtra-linguistic-wonder-procedure asserts". Moving
towards the former is a good idea. Moving towards the latter is
>> 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.
> I feel like you've started with this problem, "@trusted
> functions don't benefit from @safe checking at all", and you've
> found what seems like a good solution to it, but you haven't
> stepped back from your solution to realize that you've worked
> your way back to the existing state of affairs.
The initial motivation was concern over @safe practically
transitioning from "compiler checkable" to "not checkable
(reported) by the compiler".
> If someone shows you some code with a long @trusted function,
> and you would like @safe checks in it, you can change it to a
> @safe function with @trusted lambdas. You can do that right
> now, and that completely solves the problem of @trusted
> functions not getting checked. And this is the 2-to-1 choice of
> @trusted in Phobos. A new option of "you can leave it as
> @trusted and add @system blocks" is just the same option that
> you already have.
As hopefully understood from my earlier comments, these are,
qualitatively, not the same thing. You will still have to check
a conversion to a new style @trusted function manually of course,
no work savings there, but you'd gain something pretty important:
the compiler's assertions regarding your remaining @safe code
might actually mean something.
Also, I'm not sure how choices (2-to-1 or any N-to-1) made prior
to the availability of an alternative are to be interpreted.
What am I missing?
Finally, thanks for engaging.
More information about the Digitalmars-d