DIP 1006 - Preliminary Review Round 1

[Jonathan M Davis]

On Wednesday, March 07, 2018 14:01:31 Paolo Invernizzi via Digitalmars-d 
wrote:
> On Wednesday, 7 March 2018 at 13:32:37 UTC, ag0aep6g wrote:
> > On Wednesday, 7 March 2018 at 08:58:50 UTC, Paolo Invernizzi
> >
> > wrote:
> >> Just to understand, otherwise, if the assert is removed and it
> >> does not hold, you are in UB,
> >
> > You're not. Just let the compiler treat the code as if the
> > asserts weren't there. If the resulting code has UB, it won't
> > compile, because @safe code is statically checked to not have
> > UB.
> >
> >> so the request is to guarantee memory safety in a UB state,
> >> right?
> >
> > I don't think anyone is asking for that. The request is for no
> > UB in @safe code.
>
> Are we asking to statically check things like:
>
> Assign Expressions [1]
> Undefined Behavior:
>    if the lvalue and rvalue have partially overlapping storage
>    if the lvalue and rvalue's storage overlaps exactly but the
> types are different
>
> Is that doable, in practise?
>
> [1] https://dlang.org/spec/expression.html#assign_expressions

In places where the compiler can statically check things, it does. In the
places where it can't, it either introduces runtime checks (e.g. array
bounds checking), or it treats the code as @system, forcing the programmer
to ensure that the code is @safe, since the compiler can't determine whether
it is or not. Either way, we then get the guarantee that @safe code is
memory safe so long as @trusted is used correctly.

- Jonathan M Davis