const { panic!() } already does this.
2 Likes
I don't think that's a valid reason for introducing even more post-monomorphization errors though.
1 Like
Almost by definition yes. That is unfortunate if it is a blocker. I would argue that this isn't quite the same as what is usually meant about post monomorphization errors: this is me explicitly injecting ERROR into a type rather than, say, having a library compile and then much later finding out that the type constraints in that library don't make sense. I admit that a tricksy enough library author could possibly make that less true.
I'd also like to note that an error at "post-monomorphization compile time" is still better than an unconditional error at runtime, and that the latter is code we can write today. I'm mildly surprised nobody in this thread has written a panic_anyway macro that generates impls with just a bunch of panics.
All that said, is this enough for at least an eRFC? Or is it just dead in the water/the status quo is fine?
I didn't mean to say this is a blocker, but it's IMO an important downside over a slightly more restricting alternative that works with cargo check.
1 Like