I’ve enjoyed what I’ve gleaned from this thread and this thread and this article and this article, all referenced above (or hereabouts). One question that emerges is: would (simply) this be advisable (in our lib/application code, that is):
if (many < 2) unreachable;
? That is… is there anything wrong with promoting the use of unreachable directly, in the wild, potentially in place of calls to assert() (and the baggage of the term ‘assert’) altogether? Coupled with a true understanding of what unreachable does (and doesn’t do), one could perhaps embrace it for its own merits, and be … perhaps even “more” aware of side-effect and no-side-effect scenarios… and even cleaner coding and commenting around them? I know that I’m one who developed an allergy for putting anything side-effect-ish “inside” of macro asserts (C, e.g.); with direct unreachable grace, I might write code that is particularly obvious to readers of all sorts, even those with preconceived notions of assert(in other languages) - they won’t jump to the conclusion that some bit of code will be elided, and, if they bother to learn about unreachable, they might realize that some bits of code might be optimized when appropriate for the compiler. More advanced users can be pretty certain that bits of code will never be optimized, as long as the code contains side-effect code such as that which stores or loads through a volatile pointer, or which intentionally contains @breakpoint, e.g.