On Friday, 1 August 2014 at 01:20:04 UTC, Walter Bright wrote:
I'm rather astonished you'd take that position. It opens a huge
door wide for undefined behavior, and no obvious way of
verifying that the assume() is correct.
I'm confident that if D introduced such behavior, the very
first comment would be "I need it to insert a runtime check on
demand."
If no one else has said it, I'll be the first one to say it now:
If `assume` is implemented, the only sensible thing is to have it
verify the assumption under most circumstances and remove the
check (but keep the assumption for the optimizer to use) under
release code.
Boom, done. Sorry guys, but it's the truth, the idea of `assume`
is worthless and dangerous if there doesn't exist any way for it
to actually check the assumption when you're trying to debug your
code. Walter is absolutely right on that.
Though, I'm gonna say that `assert` doing all the things you're
suggesting it should do is a bit iffy in `@safe` code. That much
has also been shown pretty strongly as well. `assert` is
essentially an `@trusted` concept that can cause bad things to
happen in `@safe` code, but there's no real way to show the user
that. Updating the documentation on it probably won't cut it
alone. Maybe assert should be made illegal in `@safe` code or
there should be some way to mark it that it's basically trusted
to be correct (`trusted_assert`? .. or enable `@trusted` blocks
of code and make `assert` effectively `@system`? The second would
be a better feature, IMO ... more widely useful, like Rust's
`unsafe` blocks).
I think this conversation has shown a bit of a weakness in using
`assert` as currently spec'd in `@safe` code, so we probably
should come up with some proposals on how to effectively fix that
(make it obvious that bad `assert`s will break your `@safe` code).
