Simplification of @trusted

[Ola Fosheim Grøstad]

On Wednesday, 16 June 2021 at 21:55:20 UTC, Bruce Carneal wrote:
> 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.

The whole concept is kinda broken. If you have an unsafe region 
in a method then that may effect not only that method, but the 
class and all other methods. So basically the whole class, or 
maybe even the whole module, should be flagged as "@trusted".

But there is no reason to, as that can be deduced. And the 
explicit tags do not imply when it was checked nor does it say 
anything about whether the code in the class has changed after it 
was checked.

So what is good for?

For it to work you only need @unsafe markers that are as tight as 
possible, but with more detail of the nature of unsafety. For 
instance, some unsafe operations such as SIMD/casting 
optimizations can be guranteed to have only local effect. If they 
hinder @safe then that is just a compiler weakness, so you have 
to disable it to get past it. On the other hand, more global 
hacks... are quite different in nature.

As there is no way to express the nature of "unsafety", or 
whether it has been checked and what the edit timeline is for the 
surrounding code, it is not much more useful than a comment. 
Which renders the feature more annoying than useful.

Tight @unsafe is no worse than the D regime. More detailed 
information about the reason for why the region is marked @unsafe 
and when it was checked would be infinitely more useful than what 
D is doing now.