On 6/16/2021 6:09 AM, Sönke Ludwig wrote:
> There are 800 of these in vibe.d alone.

That is concerning. But it isn't necessarily cause for redesigning @trusted. For example, I removed (in aggregate) a great deal of unsafe allocation code from the backend simply by moving all that code into one resizable array abstraction.

Piece by piece, I've been removing the unsafe code from the backend. There really should be very, very little of it.


> There has also been an issue where the delegate workaround was erroneously flagged as a heap delegate, causing considerable GC memory load.

I can't think of a case where:

() @trusted { ... }();

would make it a heap delegate. Such cases should be in bugzilla.


> `@trusted` *should* probably not even be available for functions (of course it is not a desirable breaking change to disallow that now, though).

The idea is to encourage programmers to think about organizing code so that there are clear separations between safe and system code. Interleaving the two on a line-by-line basis defeats the purpose.

On 16.06.21 23:22, Walter Bright wrote:
> 
>> `@trusted` *should* probably not even be available for functions (of course it is not a desirable breaking change to disallow that now, though).
> 
> The idea is to encourage programmers to think about organizing code so that there are clear separations between safe and system code. Interleaving the two on a line-by-line basis defeats the purpose.

Yes. This.

On Wednesday, 16 June 2021 at 18:28:48 UTC, Timon Gehr wrote:
> On 16.06.21 13:38, RazvanN wrote:
>> 
>> 
>> What do you think?
>
> @trusted nested functions are an antipattern and this enshrines them in a language feature.

Yes.

Making it trivial to circumvent @safe weakens it broadly and across time.  I would rather see the language move towards more readable/maintainable safety dependencies and additional automated checking.

I like the notion that others have mentioned of @safe checking by default within @trusted code (which would require @system blocks to disable checking).  Perhaps we could adopt an opt-in strategy where such @safe checking is triggered by the presence of an @system block.

If adopted, we might later move to @safe-within-@trusted-by-default via compiler flags or module attributes or ...

On Wednesday, 16 June 2021 at 21:26:08 UTC, Bruce Carneal wrote:
> I like the notion that others have mentioned of @safe checking by default within @trusted code (which would require @system blocks to disable checking).  Perhaps we could adopt an opt-in strategy where such @safe checking is triggered by the presence of an @system block.

Under this proposal, @system lambdas/blocks within @trusted code would have the exact same semantics as @trusted blocks/lambdas within @safe code currently do. It's pure bikeshedding.

On Wednesday, 16 June 2021 at 21:32:46 UTC, Paul Backus wrote:
> On Wednesday, 16 June 2021 at 21:26:08 UTC, Bruce Carneal wrote:
>> I like the notion that others have mentioned of @safe checking by default within @trusted code (which would require @system blocks to disable checking).  Perhaps we could adopt an opt-in strategy where such @safe checking is triggered by the presence of an @system block.
>
> Under this proposal, @system lambdas/blocks within @trusted code would have the exact same semantics as @trusted blocks/lambdas within @safe code currently do. It's pure bikeshedding.

I assumed that what Bruce is saying is that if you have a @system block within @trusted code, then the remainder of the @trusted code gets @safe checking. That's not the same thing.

On 16.06.21 23:32, Paul Backus wrote:
> On Wednesday, 16 June 2021 at 21:26:08 UTC, Bruce Carneal wrote:
>> I like the notion that others have mentioned of @safe checking by default within @trusted code (which would require @system blocks to disable checking).  Perhaps we could adopt an opt-in strategy where such @safe checking is triggered by the presence of an @system block.
> 
> Under this proposal, @system lambdas/blocks within @trusted code would have the exact same semantics as @trusted blocks/lambdas within @safe code currently do. It's pure bikeshedding.

I wouldn't even bother if that was the case.

The semantics is different if you consider code evolution and properly assigning blame for bugs.

@safe code is code you don't have to check for memory safety errors.

You can try to move the goal posts, but the title of this discussion is "simplifying @trusted", not "redefining @safe".

On Wednesday, 16 June 2021 at 21:22:32 UTC, Walter Bright wrote:
> [snip]
>> `@trusted` *should* probably not even be available for functions (of course it is not a desirable breaking change to disallow that now, though).
>
> The idea is to encourage programmers to think about organizing code so that there are clear separations between safe and system code. Interleaving the two on a line-by-line basis defeats the purpose.

This is a better argument against @trusted blocks within @safe blocks than it is against @system blocks within @trusted code.

On Wednesday, 16 June 2021 at 21:32:46 UTC, Paul Backus wrote:
> On Wednesday, 16 June 2021 at 21:26:08 UTC, Bruce Carneal wrote:
>> I like the notion that others have mentioned of @safe checking by default within @trusted code (which would require @system blocks to disable checking).  Perhaps we could adopt an opt-in strategy where such @safe checking is triggered by the presence of an @system block.
>
> Under this proposal, @system lambdas/blocks within @trusted code would have the exact same semantics as @trusted blocks/lambdas within @safe code currently do. It's pure bikeshedding.

The difference is in ease of maintenance.  Things should nest properly wrt human comprehension.

In the "bikeshedding" proposal @safe code need not be checked manually while the @trusted code, which already needed to be checked manually, will now enjoy a narrowing of focus.

Perhaps I'm missing something here.  If so, please enlighten me as to the advantages of the "non-bikeshedding" approach and/or the errors in my logic.