> You can use `.value()`

Which is bad at every level if resolution: it’s more verbose to do “the right thing” (obviously), it’s more expensive to do “the right thing” (because if you’ve properly checked you’re paying the check twice and praying the compiler can remove the redundant check), and it’s incompatible with other pointers to do “the right thing” (because pointers use ! And *).

So .value() it mostly worthless, if it’s being used it’s an assertion with overhead which can take down your program.

> all the people who wanted it for the purposes of eschewing exceptions, the crowd who wanted `std::optional` the most, would be getting the verbose code.

And nothing of value would be lost (except for it not behaving as a “standard pointer” anymore).

> it’s more expensive to do “the right thing” (because if you’ve properly checked you’re paying the check twice and praying the compiler can remove the redundant check)

Eh that's hardly a solid complaint here. Since these are header-defined templates, it's all inlined. And any compiler will absolutely remove those redundant checks as a result. And an unchecked .value() would still be available if you really did object to that "overhead", so it doesn't violate any C++ principals here.

I do kinda think that operator-> & operator* as a result did the assertion, and value() bypassed it. But this would also be the opposite behavior of other std:: classes, like std::vector (operator[] being unchecked vs. at() being checked).

I do not think it is. What does the language do on * dereferencing? Yes, it does not do a check. So if you do it now you have to remember two different rules, one rooted deep inside C and C++ minimal overhead philosophy. Now multiply by the number of types (unique_ptr, shared_ptr, optional and probably more) and remember the correct rule.

I do not think there is something bad with it. It does the same for the same syntax and you have a `.value()` checked access anyway.

> praying the compiler can remove the redundant check

It can in pretty much every single case even on -O1.

I somehow have my doubts if that check was made in entirely different parts of the program

What do you mean?

Throwing an exception is somewhat better but still not what I really want, usually. I want the compiler to make me write an if()-like statement checking if the value is non-null before I can dereference it.

Try/catch is if-like if you do it right.... But it's also not mandatory. Hence the argument for Java's checked exceptions... which didn't pan out in the end.

Throwing exceptions in C++ is also incredibly slow, you generally don't want to do it in any path that you expect will actually be exercised in normal operation.

Checked exceptions were a nice idea in theory that definitely didn't work well at all in practice. IMO exceptions should be reserved for "panic" situations, as a friendlier alternative to crashing. (But I also feel they should be used liberally in such situations...)

I cut my teeth on Python's "forgiveness not permission" model and find that exceptions are usually the cleanest model since so few languages have pleasant syntax for alternate return-types, and returning a status code and using out parameters for the actual result is miserable.

Sure but python was built on a model of signalling anything via exceptions, C++ was not, and it sacrifices the exceptional case for the benefit of the nom-exceptional one.

Using exceptions for control flow etc. etc.

Disabling exceptions means that you can't catch them, not that you can't throw them.* If an exception would be thrown under such circumstances, the process aborts. This would have been a safer default than undefined behavior (though inconsistent with other fundamental and standard C++ APIs, which generally prefer for the obvious default to be fast rather than safe).

* This is technically wrong, because, e.g., destructors don't run on the way out; I'm going for pithiness here rather than strict accuracy.