Simplification of @trusted

[Ola Fosheim Grøstad]

On Wednesday, 16 June 2021 at 22:54:51 UTC, Bruce Carneal wrote:
> 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.

Well, but the problem is at a more fundamental level. When 
writing code we make assumptions about invariants on various 
levels. So when auditing unsafe code you audit it with respect to 
local and global invariants.

For instance, if I write a program with GC turned off as an 
invariant. Then I might audit code that packs information into 
lower bits of addresses in pointers values as safe. Then some 
other guy takes over the code base and decides to turn on the GC. 
Well, effectively the program is broken at a global level, 
because the actual scope of @trusted that we can be certain of is 
the whole program! :-D

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

As long as people continue to modify, refactor, redesign and 
change invariants then you need something more explicit.

For instance if my unsafe region had been marked with a tag that 
said pointer-value-manipulation, and you have a timestamp on it, 
and you have an association between pointer-value-manipulation 
and turning on GC, then the compiler could start listing all the 
weak spots that has to go through a new audit.

But with no knowledge of WHY a region is unsafe, when it was 
audited and how/when the surrounding changed, the compiler can't 
do much, so we are left with a feature that essentially does 
nothing.

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

No, @safe does something, but you cannot know what the scope of 
@trusted should be, because even global invariants can change. So 
you might as well do what other languages do and just put an 
"unsafe" compiler-bypass-checking-silencer on the offending 
statement/expression.

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

Ok, but it doesn't do anything more than a comment.

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


For it to work, you need to list all the invariants that the 
audit of the unsafe region makes assumptions about.

With such a list you could actually trigger warnings about unsafe 
regions when the invariants change.

Scope is not really meaningful. The scope of the unsafe statement 
is unknown, because the code base is changing.