On Sunday, 25 July 2021 at 13:19:55 UTC, Paul Backus wrote:
>On Sunday, 25 July 2021 at 05:05:44 UTC, Bruce Carneal wrote:
>At beerconf I committed to putting forward a DIP regarding a new syntactic element to be made available within @trusted functions, the @system block. The presence of one or more @system blocks would enable @safe checking elsewhere in the enclosing @trusted function.
Both before and after this proposal, there are 3 kinds of code:
- Code that is automatically checked for memory safety.
- Code that is assumed by the compiler to be safe, and must be manually checked for memory safety.
- Code that is not checked for memory safety, and is assumed to be unsafe.
Currently, (1) is marked @safe
, (2) is marked @trusted
, and (3) is marked @system
.
Under this proposal, (1) would be marked either @safe
or @trusted
, (2) would be marked either @trusted
or @system
, and (3) would be marked @system
. I do not think this is an improvement relative to the status quo.
There is no getting away from manually checking the @system block(s) so (2) would be , IIUC, just as it is now wrt compiler assumptions.
The improvements on the status quo include the ability to easily delimit "should check very closely" code and the corresponding ability to engage @safety checking on any remainder.
> >The problematic @trusted lambda escapes creeping in to "@safe" code could be replaced going forward by a more honestly named form, @trusted code with @system blocks. Best practices could evolve to the point that @safe actually meant @safe again.
What makes @trusted
lambdas problematic is that they implicitly depend on everything in their enclosing scope, which makes it easy for a change in the @safe
portion of the code to accidentally violate an assumption that the @trusted
portion depends on.
Yes.
>If we want to address this issue at the language level, the most direct solution is to require that @trusted
lambdas make their dependencies explicit. This can be done by requiring all @trusted
nested functions (of which lambdas are a special case) to be static
.
Yes. As Walter has put this, we'd be forcing args/operands to "come in through the front door" rather than sneaking in the back.