assume, assert, enforce, @safe

[Chris Cain via Digitalmars-d]

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).