Programming Languages on Crack

[Ola Fosheim Grøstad]

On Thursday, 17 June 2021 at 02:02:58 UTC, Walter Bright wrote:
> The idea of putting it at the function level is to force (I 
> know,
> that sounds bad, but indulge me for a moment) the programmer
> to think about the decomposition of programs into safe and 
> unsafe
> code. Ideally, untrusted code should be encapsulated and 
> segregated
> into separate sections of code, with clean, well-defined, 
> well-considered,
> and well thought through interfaces.

Then you have to make the "calls unsafe code" marker transitive. 
Which is completely unreasonable.

It is a mistake to think that unsafety is related to interfaces. 
That would only apply to the most trivial usage of unsafe code.

If @safe is meant to be useful then it should be done in a way 
that makes people want to use it. That includes people who 
currently slap @system all over their code base. That includes 
people who write kernels and device drivers.

If you want people to use safety features then you also have to 
design it in a way that makes people not hate their code base.

> At statement level, one just schlepps @trusted in front and 
> gives it
> no more consideration. It is thoughtlessly applied, the 
> compiler error
> goes away, Mission Accomplished!

Slapping one @trusted over the whole function is even easier than 
slapping two @trusted on 2 statements inside the function body.

So that argument makes no sense to me.

(Also "@trusted" looks far more innocent to newbies than 
"@unsafe", but that is another issue.)

> It might as well be renamed
> the @shaddup attribute. Zero thought is given to carefully 
> crafting
> a safe interface, because a safe interface to it is not 
> required.

Your lexer in DMD will obviously never be safe as it is written. 
It can be made trusted, but if @safe code overwrite sentinels 
then it will obviously break.

In actual system level code you cannot make the assumption that 
memory safety is related to interfaces. It is related to 
datastructures, events and timelines and their invariants.


> As for my own pre-safe code, I've been gradually upgrading it 
> to be
> fully @safe. It's a satisfying result.

Well, all of dmd can be rewritten to be @safe with no problem. As 
is the case for most batch programs.

But a compiler is not really system level code.

> P.S. A subtler aspect of this is D's semantic reliance on rich 
> function
> signatures. This passes critical semantic information to the 
> compiler,
> such as inputs, outputs, escapes, live ranges, who's zoomin' 
> who, etc.
> Having @trusted at the statement level, with no defined 
> interface to it,
> just torpedoes the compiler's ability to reason about the code.

Easy solution: make @trusted inferred, and introduce @unsafe at 
the statement level.

Then let IDEs annotate call chains with some kind of syntax 
highlighting or other marker that lets people know that a call 
chain includes @unsafe code.

One thing that makes people dislike the look of D code is exactly 
those "rich" function signatures. It has a negative impact on 
programmers ability to interpret function signatures. Especially 
newbies.

It is easier to just slap @system on the whole code base. If you 
write system code. Which also is the kind of code that could 
benefit most from @safe...