@system blocks and safer @trusted (ST) functions

[jmh530]

On Tuesday, 27 July 2021 at 21:05:52 UTC, jfondren wrote:
> [snip]
>
> Presently D is shoehorning two different usages into 
> @safe/@trusted/@system:
>
> 1. the documented usage: @safe for checked @safe functions, 
> @system for unrestricted functions, and @trusted for a 
> manually-reviewed interface between the two. (complaint: 
> @trusted functions check too little)
>
> 2. a usage people have moved to, where the manually-reviewed 
> interfaces are now @trusted function literals embedded inside 
> @safe functions. (complaint: '@trusted blocks' are too hard to 
> review and their containing @safe functions are misleadingly 
> 'safe')

I don't use @trusted function literals. I don't have a sense of 
how popular this usage is. In the context of my suggestion, an 
@trusted literal that is @blacklist would result in @safe that is 
@blacklist, which would make it a candidate for review.

>
> So that's already two ways to write SafeD code and both are 
> found wanting. With @whitelist/@blacklist there'd be a third 
> way. At that point, why not a fourth? I'm sure some people 
> would like a single @unsafe attribute, and maybe it could be 
> justified by a late discovery of a serious complaint with 
> @whitelist/@blacklist. And then we could have a function 
> signature containing `@trusted @whitelist @unsafe`, and then we 
> could have a "The Nightmare of Memory Safety in D" video at 
> cppcon.
> [snip]

The underlying problem is how to fix design issues with 
@safe/@trusted/@system while minimizing code breakage. Only the 
bare minimum to address those issues would make sense. Adding an 
@unsafe that overlaps with existing or proposed functionality 
wouldn't make sense.