In this world, as the document you've linked says: "The behavior is undefined if *this does not contain a value."
The operators for such access are actually `noexcept` - the exception you're apparently relying on would be illegal.
Once in a while I go down a rabbit hole, but hey, it's not as though HN isn't a rabbit hole anyway.
Of course not, they’re literally `noexcept`, what they do is UB if empty.
value() will throw.
This feels like an easy choice in isolation, but at the time this was being developed (and arguably even now), there’s no definitive plan to holistically move C++ code to being safe by default. So whenever that happens, a ton of things will need to be dealt with, and there’s always the possibility that being an odd API here makes that overall move harder not easier. And C++ is regularly criticized for being inconsistent. Do you deepen those criticisms just so that one tiny corner of an API is better?
If I’m honest with myself, I probably would have made the same choices they did in this situation.
Some of the more modern proposals (std::optional is quite old) actually make an explicit appeal to WG21 not to choose consistency at the price of safety because it just needlessly makes the language worse. "But we made the language worse before" is more like a plea for help than an excuse.
Barry Revzin did this in his "do expressions" which are an attempt to kludge compound expressions into C++ which really wants them to be compound statements instead. For consistency, all the obvious mistakes you'll make in do expressions could introduce UB like they would in equivalent C++ core features, but Barry argues they should be Ill-Formed instead - resulting in your mistakes not compiling rather than having undefined behaviour.
Implicit conversion that immolates: imolicit conversion.