@system blocks and safer @trusted (ST) functions

[jfondren]

On Tuesday, 27 July 2021 at 16:36:48 UTC, jmh530 wrote:
> On Sunday, 25 July 2021 at 21:42:16 UTC, Ali Çehreli wrote:
>> [snip]
>> Existing code:
>>
>> 1) Replace @safe keywords with @trusted where the compiler 
>> complains. (No safety lost because @trusted will be behaving 
>> exactly like today's @safe.)
>>
>> 2) Add @system where the compiler complains. This is because 
>> all code is @trusted by default and @trusted is safe.
>>
>> Ali
>
> I'd much rather add new attributes for new behavior than break 
> existing code. If you want @safe to not be able to call 
> @trusted functions, then introduce a new attribute with that 
> behavior.
>
> I think too much is trying to get shoehorned into the 
> @safe/@trusted/@system dichotomy.
>

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')

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.

Opposite the Scylla of "breaking code" isn't safe open water, but 
the Charbydis of "having to explain SafeD to a skeptical newbie." 
Why five attributes? Because three wasn't enough.

The immediate result of this DIP would also be three SafeD styles:

1. legacy code doing it as previously documented, #1 above

2. legacy code doing it with '@trusted blocks', #2 above

3. the new way of @safe functions without compromise, @trusted 
functions containing @system blocks, and @system functions

But as #3 solves the problems people had with #1 and #2, the 
farther-off result is just one SafeD again, this time also with 
the documentation matching what experts actually do.