@system blocks and safer @trusted (ST) functions

[Bruce Carneal]

On Sunday, 25 July 2021 at 14:38:18 UTC, Paul Backus wrote:
> On Sunday, 25 July 2021 at 14:34:27 UTC, Bruce Carneal wrote:
>>
>> I'd like to have assistance from the compiler to the maximum 
>> extent possible and then conduct the code review(s).  Assuming 
>> low (near zero) false positives out of the compiler, I'm not 
>> sure why one would prefer manual checking when compiler 
>> checking was available, but that option is certainly available 
>> in both the current and proposed environments.
>
> Under your proposal, the proportion of code that must be 
> manually-checked vs. compiler-checked does not change at all.

The direct translation of an embedded lambda @safe function to 
the corresponding trusted/@system leaves you with the exact same 
amount of work at the point of translation wrt that function, 
without dispute.

Machine advantage comes in other forms.  Firstly, we now have a 
properly segregated code base.  @safe always means 'machine 
checkable'.  Zero procedural @trusted code review errors in that 
now easily identified class.

Another possible benefit (hypothesis only here) is the ease with 
which existing @trusted code can be made @safer.  External 
clients already believe that you're @trusted, so at any time you 
can become @safer, incrementally (shrink the, initially large, 
@system block(s)).  More machine checking available along a 
reduced friction path. TBD.

Another possible benefit (bigger leap of faith here) is that the 
continuously-variable-safety mechanism will encourage safer 
coding generally by reducing the friction of moving functions the 
other way, from @system code to @safer trusted. More machine 
checking available along a reduced friction path.  Again, TBD.

Another possible benefit is that all new @trusted code would 
start with a form that defaults to @safe (you opt out). I think 
that defaults matter and that this one would lead to more machine 
checkability passively,or "by default".  No need to wait for the 
"right" time to move to @safe with @trusted escape, just evolve 
the code.

Architecture matters more here than the exact forms most would 
say, and I'd mostly agree, but I believe the forms are important.

I also believe that there are other benefits, primarily in terms 
of human visuals (more easily discerned and more easily 
localizable @system regions) but the above are what come to mind 
wrt machine checkability.

I'm still thinking about it.  It's less work if this is 
destroyed, so keep those sharp critiques coming! :-)