Programming Languages on Crack

[ag0aep6g]

On 17.06.21 04:02, Walter Bright wrote:
> The ()@trusted{ ... }() is equally bad. Note that there are no parameters
> to it, hence NO interface. This was discovered as a way to evade the
> intent that @trusted was to be applied to a function interface. It
> had never occurred to me to add semantics to disallow it. Even worse,
> I myself have been seduced into using this trick.

It still has an interface, of course. The surrounding context acts as 
one large `ref` parameter. Strictly speaking, the programmer must ensure 
that the @trusted nested function doesn't create unsafe values in the 
outer function.

Everyone conveniently forgets that when writing @trusted nested 
functions. Just like everyone conveniently forgets that all(!) @trusted 
functions must have safe interfaces. But a review process that is 
serious about @trusted could catch those errors and force programmers to 
use it as intended.

However, even the standard library has more than enough instances of 
strictly-speaking-incorrect @trusted. So maybe it's time to give the 
users more features that make help with writing correct @trusted code. 
@system variables is one [1]. @system blocks in @trusted functions with 
special semantics as proposed earlier in the discussion is another.



[1] https://github.com/dlang/DIPs/blob/master/DIPs/DIP1035.md