Origins of the D Programming Language

[Jonathan M Davis]

On Saturday, December 1, 2018 8:00:35 AM MST Timon Gehr via Digitalmars-d 
wrote:
> On 30.11.18 20:34, Andrei Alexandrescu wrote:
> > Over the past few months, Walter, Mike, and myself have been working on
> > a draft submission for the HOPL 2020 conference (History of Programming
> > Languages).
> >
> > The submission proceeds in several stages. Currently we've been through
> > one round of preliminary review. Here is the current draft:
> >
> > http://erdani.com/hopl2020-draft.pdf
> >
> > We'd appreciate feedback and additional historical details.
> >
> >
> > Thanks,
> >
> > Andrei (on behalf of Walter and Mike as well)
>
> Great write-up!
>
> Comments:
>
> 110-111: UB on assertion failure is still terrible even if it is
> considered to be a bug and a non-recoverable error. Those things have
> nothing to do with each other. The airplane analogy would be roughly:
> "Components that are about to fail may start to arbitrarily violate the
> laws of physics."

UB on assertion failure fundamentally breaks the guarantees of @safe. @safe
is supposed to guarantee that invalid memory accesses cannot occur (assuming
that @trusted code was properly vetted anyway), whereas allowing UB on
assertion failure violates that, because it makes it so that memory safety
is not guaranteed if an assertion every fails. IIRC, the spec even
specfically states that @safe code is not allowed to have UB, and as I
understand it, if it's allowed to have UB, then the optimizer can make the
code @system in spite of it being marked as @safe, because the optimizer can
assume pretty much whatever it wants about code which is UB (e.g. as I
understand it, that currently happens with ldc if it ever detects that a
pointer or reference is null and is then dereferenced, because it treats
dereferencing null as UB - I don't know if dmd has a similar problem). If
assertion failures are allowed to introduce UB, then assertions should be
treated as @system, not @safe.

Really, at minimum, assertions should not be allowed to introduce UB in
@safe code, and even allowing it in @system code gets iffy, because UB makes
it extremely difficult for the programmer to properly vet the code for
memory safety so that that they can properly mark the code as @trusted. I
don't think that optimizing based on assertions is necessarily bad, but the
optimizations need to be restricted such that they're not allowed to make it
so that the code is not memory safe if the assertion fails. Without that, I
don't see how we could reasonably argue that @safe code is memory safe if it
contains assertions.

- Jonathan M Davis