4 ms·

> Aside: IMO std::optional in general is disappointing because it doesn't actually solve the worst problem with nullable pointers: dereferencing a null std::opt

> Aside: IMO std::optional in general is disappointing because it doesn't actually solve the worst problem with nullable pointers: dereferencing a null std::optional is still undefined behavior. I wish the standard had gone with a design that forces the developer to write an explicit check when unwrapping the optional... You can use `.value()` to deref an optional instead of `operator*` or `operator->`. It will throw an exception on empties. IMHO the primary purpose for a function returning a `std::optional` instead of either returning a value on success or throwing an exception on failure is that you can use it in codebases where exceptions are disabled for whatever reason. If the behaviors of `.value()` vs `operator*` were swapped, such that `operator*` throws exceptions and `.value()` is undefined behavior, 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.

masklinn 5y ago
> 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).
- kllrnohj 5y ago
  > 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).
- junon 5y ago
  > praying the compiler can remove the redundant check It can in pretty much every single case even on -O1.
  - kitkat_new 5y ago
    I somehow have my doubts if that check was made in entirely different parts of the program
    - junon 5y ago
      What do you mean?
- germandiago 5y ago
  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.
kentonv 5y ago
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.
- Pxtl 5y ago
  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.
  - kentonv 5y ago
    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...)
    - Pxtl 5y ago
      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.
      - masklinn 5y ago
        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.
  - hoseja 5y ago
    Using exceptions for control flow etc. etc.
ameliaquining 5y ago
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.

masklinn 5y ago

> 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).

kllrnohj 5y ago
> 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).
junon 5y ago
> praying the compiler can remove the redundant check It can in pretty much every single case even on -O1.
- kitkat_new 5y ago
  I somehow have my doubts if that check was made in entirely different parts of the program
  - junon 5y ago
    What do you mean?
germandiago 5y ago
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.

kentonv 5y ago

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.

Pxtl 5y ago
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.
- kentonv 5y ago
  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...)
  - Pxtl 5y ago
    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.
    - masklinn 5y ago
      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.
- hoseja 5y ago
  Using exceptions for control flow etc. etc.

ameliaquining 5y ago

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.