On Mon, May 17, 2021 at 7:16 PM Jens Gustedt <jens.gustedt_at_[hidden]> wrote:
>
> I am not sure that `abort` tells anything else than this path of control flow is catastrophic. So yes, for tiny bit of additional sugar with the possible message, but that's it, I think.

It tells the reason why the path is not supposed to be reached.
Standardizing the most common reasons is a good thing in my view, and
I appreciate that Rust has things like `unreachable!`,
`unimplemented!`, `todo!`, `panic!`. All of those end up as a panic,
but the reason for panicking is different.

> Frankly, I don't see in this case how a safe version would make much sense. Such a function is the opposite of safe, we are telling the compiler that, against all evidence, this path will never be taken.

The safe version is the aborting one.

> I think you are arguing in the wrong direction ;-) One possible implementation of such a thing would be `assert(false)`.
>
> UB is not a specific behavior, it is the absence of requirements for behavior.

Sure, but in terms of the spec it is not the same, and as a user I
would expect different codegen from an optimizer. That is why I would
be using an unsafe `unreachable()`, after all.

> But what I meant, was that having a feature that behaves fundamentally different under debugging makes it impossible to debug the feature when it is applied with all of its strength. For me that has much resemblance with a nightmare.

I agree differing behavior is best avoided in general, but having an
easy way to debug all `unreachable()`s in a program (e.g. running the
test suite to check nothing hits one of them) seems like a good idea.

IIRC, some people argued to have this kind of thing within the C++
contracts discussions too.

Cheers,
Miguel