Simplification of @trusted

[Bruce Carneal]

On Wednesday, 16 June 2021 at 22:21:22 UTC, Ola Fosheim Grøstad 
wrote:
> 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".

We all work to isolate dependencies, safety related and 
otherwise, so that we can reason about the whole with more 
confidence.  Whenever we introduce something that impedes our 
ability to "treeify" dependencies, something that makes analysis 
more of a graph analysis than a tree analysis, we've done 
something that has made maintenance and code-reuse more difficult.

At the language level we can't stop programmers from writing code 
with nasty dependencies but we can make it easier to write code 
with fewer entanglements.

>
> 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?

Perhaps I misunderstand you but I'd say it's good for a lot. As a 
contrasting exercise one can think about what would happen if 
@safe/@trusted/@system became compiler noops starting tomorrow 
and forevermore.

Yes, I think things can be made better but there's already, to my 
way of thinking at least, a lot of value.

>
> For it to work you only need @unsafe markers that are as tight 
> as possible, but with more detail of the nature of unsafety. ...

I think that finer granularity/specificity might be useful, 
particularly if can improve basic readability/nesting.