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
