DIP 1006 - Preliminary Review Round 1

[Jonathan M Davis]

On Tuesday, March 06, 2018 02:17:42 Walter Bright via Digitalmars-d wrote:
> On 3/6/2018 1:58 AM, Jonathan M Davis wrote:
> > [...]
>
> The entire point of making assert a core language feature was so that the
> compiler could take advantage of it to generate better code. It's been
> like that for D since day 1. It has always been documented to do that. It
> has been discussed many times in this n.g. over the years with loooong
> threads. I designed it that way so that D could potentially produce
> better code than other languages in ways they could not match.
>
> There is no other purpose to making it a core language feature.
>
> It's fine if you want an assert-like feature to have other semantics -
> just define one called 'check', give it the semantics you want, and put
> it in the library. As I mentioned to Timon, support for that sort of
> thing is why D has special support for __LINE__ and __FILE__.
>
> Or just don't turn off assert checking. Personally, I use asserts in a way
> that they add little overhead so they can remain active in the release
> build.
>
> It's entirely under your control.

I don't mind if assertions allow the compiler to better optimize. What I
object to quite strongly is about the compiler being allowed to introduce
optimizations that violate @safety guarantees. Built-in features should not
result in @safe code invisibly becoming @system. That violates the entire
purpose of @safe.

I don't see how this situation is any different from the array bounds
checks, and those aren't compiled out in @safe code - even when assertions
are compiled out.

- Jonathan M Davis