Simplification of @trusted

[Bruce Carneal]

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

Fundamental problems sometimes admit incremental improvements 
towards resolution.  I'm more disposed to 
improvement-through-simplifying-but-possibly-large-rewrites than 
incremental change but in this case I'd go with incremental.

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

Sure, we have responsibility for the whole program.  Anything 
that lets us confidently subdivide that problem is welcome.

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

I disagree.  I believe that more general mechanisms can help that 
do not preclude the finer granularity mechanisms which you 
advocate (and which I am interested in).

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

I believe providing the compiler with more information can be a 
very good thing, perhaps worthy of another thread.

>
>> 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, @trusted works within a broader framework, a *manually 
managed hence dangerous* framework.  A practical path forward is 
to improve the compilers ability to check things and 
localize/minimize the unchecked.  As far as how the programmer 
deals with all the rest, well, I'd say we're back to "best 
practices" and "convention".

We all want the language/compiler to do more on the safety front, 
at least if improvements come at very little coding 
inconvenience, but something like an @trusted transition zone 
will be needed at the, evolving programmer defined, boundary 
between machine checkable and "you're on your own".

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

In line with my comments both above and below, I disagree.

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

Yes.  The compiler will need enough information to act.

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

If I understand your meaning here, I disagree.  I think 
@safe/@trusted is very useful, essential even, in code bases that 
are changing.  It is a demarcation tool that lets us carve out 
ever larger safe areas.