DIP 1006 - Preliminary Review Round 1

[Jonathan M Davis]

On Wednesday, March 07, 2018 08:39:30 Paolo Invernizzi via Digitalmars-d 
wrote:
> On Tuesday, 6 March 2018 at 20:03:11 UTC, Jonathan M Davis wrote:
> > On Tuesday, March 06, 2018 18:49:42 Paolo Invernizzi via
> >
> > Digitalmars-d wrote:
> >> I simply don't understand why enforce or a custom check can't
> >> be used @safe code, if you want that behaviour.
> >>
> >> If the program must HALT on this or that, well, what is better
> >> than an explicit piece of unremovable code that do that?
> >> Instead of writing 'assert', one should write 'enforce'.
> >
> > 1. It's quite common for folks to want to add debugging checks
> > that are compiled out in -release. That's exactly what assert
> > is for in pretty much every lanugage that has it. It's what
> > folks expect to use and what your average programmer will use
> > without thinking about @safety issues at all. It's what
> > everyone uses right now, and I'm pretty sure that almost
> > everyone using it has no clue that Walter considers it okay for
> > assertions to introduce optimizations which are not memory
> > safe, and if/when he does do so, a lot of D code will suddenly
> > have @safe code which is not memory safe. Such problems will
> > hopefully be hit rarely, because hopefully, the code will have
> > been well-tested, and the assertions will have found all of the
> > related bugs, but there's every possibility that some bugs will
> > manage to not be caught, thereby resulting in @safe code being
> > unsafe. No one is going to be looking to use solutions other
> > than assertions for what assertions are for unless we start
> > telling everyone to avoid assertions, because they make @safe
> > code unsafe. And honestly, if assertions make @safe code
> > unsafe, I don't see a good argument for using them at all. If I
> > didn't care about code being @safe, I wouldn't be using @safe.
> > @safe is supposed to guarantee that the code is memory safe.
>
> Understood. Are asking that UB should not include memory
> corruptions?

I'm saying that whatever optimizations are enabled by assertions should be
guaranteed to not include memory corruptions.

> > 2. I think that it's fundamentally a terrible idea to allow
> > built-in language features to violate @safe. Aside from issues
> > related to @trusted being misused, @safe code should be
> > guaranteed to be memory safe, and it should be considered a bug
> > any time that it isn't. That's why @safe exists. No one should
> > have to be looking at @safe code to track down memory safety
> > problems. And if they do, then @safe is not doing it's job.
> > Array bounds checks are left in @safe code for exactly these
> > reasons.
>
> So, the request is to just leave assert active as a default in
> @safe code, like the bounds checks?

No. I'm saying that no optimizations should be enabled which introduce
potential memory corruption. Assertions should have zero impact on whether
code is @safe or not unless the code in the condition or which is generating
the message for the assertion is @system, and it's no more reasonable to
assume that an assertion is going to pass than it is to assume that bounds
checking won't fail. Regardless, the key thing here is that @safe code
should be guaranteed to be @safe so long as @trusted code is vetted
properly. It should _never_ be possible for the compiler to introduce memory
safety issues into @safe code.

> > I'm all for introducing optimizations that do not violate
> > @safe, but if we allow @safe code to be unsafe, then why do we
> > even have it?
>
> So, the reasoning is that UB should not lead to memory
> corruption, right?

The reasoning is that no @safe code should ever have memory corruptions in
it unless it calls @trusted code that was incorrectly vetted by the
programmer. The compiler is supposed to guarantee that @safe code is @safe
just like it's supposed to guarantee that a const variable isn't mutated or
that a pure function doesn't access mutable, global variables. And as such,
introducing anything into @safe code which could be memory unsafe is a
violation of the compiler's responsibility.

- Jonathan M Davis