6 ms·

Note the original title is: T* makes for a poor optional<T&> The last `<T&>` there is key, but seems to have been removed from the HN version of the title. Th

Note the original title is: T* makes for a poor optional<T&> The last `<T&>` there is key, but seems to have been removed from the HN version of the title. This blog post is not arguing for the use of optionals in general (it assumes everyone already agrees with that). It is instead making a much more wonky argument that std::optional<T> should support T being a reference type, which apparently is not supported right now. For most purposes, it seems std::optional<T&> would behave very similarly T*, but the ergonomics would be better in certain template scenarios. It seems like a valid argument to me, but definitely getting into the weeds a bit. 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...

strager 5y ago
> I wish the standard had gone with a design that forces the developer to write an explicit check when unwrapping the optional... If this is how std::optional worked, hardly anyone would use it.
- winter_squirrel 5y ago
  Why, other languages that require unwrapping it still see plenty of people using optional. In fact, I would have more inclination to use it in my projects if that was the only way to do it.
- kentonv 5y ago
  > If this is how std::optional worked, hardly anyone would use it. OK... Well, this is how kj::Maybe works and having written several hundred thousand lines of code using it, I think it works well. https://github.com/capnproto/capnproto/blob/master/kjdoc/tour.md#maybes https://github.com/capnproto/capnproto/blob/master/kjdoc/tou...
  - kllrnohj 5y ago
    Well, that seems to be using macros to cover up the syntax, which of course the C++ committee isn't going to recommend or use for anything new (nor should they). The actual implementation of Maybe doesn't seem to force anything, it just returns a pointer to the stored value. There's no enforcement of any kind that anything is checked as a result. There's some hoop-jumping with friend classes to "hide" the readMaybe() function to make the non-macro usage as ugly as possible to strongly encourage using the macro-convention, but that's hardly "enforcement". It's a cute syntax & macro pattern, but it's hardly a good fit for a C++ standard, either.
    - kentonv 5y ago
      The C++ committee could come up with actual syntax for this so it doesn't need macros. > There's no enforcement of any kind that anything is checked as a result. There's some hoop-jumping with friend classes to "hide" the readMaybe() function to make the non-macro usage as ugly as possible to strongly encourage using the macro-convention, but that's hardly "enforcement". Sure fine. Anyone who wants to reach into the internal APIs could also just as easily do `#define private public` and bypass every protection C++ has. We're not trying to defend against malicious developers here.
- brandmeyer 5y ago
  To be fair, languages which require explicit unwrapping also provide syntactic short-hands for the most common idioms. Long-handed if/else (or pattern matching) is used to implement the short-hands or as a last resort. See also value_or and the C++20 monadic methods on std::optional. http://open-std.org/JTC1/SC22/WG21/docs/papers/2021/p0798r6.html http://open-std.org/JTC1/SC22/WG21/docs/papers/2021/p0798r6....
- kamray23 5y ago
  that is how it works everywhere else and that is how it is used everywhere else
  - jcelerier 5y ago
    how is that an argument ? If I was fine with how any other language does things (and $deity knows I've tried a lot) I would not be using c++
    - chupkarkhotay 5y ago
      there's no cure for poor taste
nwallin 5y ago
> 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).
colejohnson66 5y ago
> Note the original title is: T* makes for a poor optional<T&> > The last `<T&>` there is key, but seems to have been removed from the HN version of the title. HN seems to like stripping out HTML-tag-like blocks instead of escaping them. Why though?

strager 5y ago

> I wish the standard had gone with a design that forces the developer to write an explicit check when unwrapping the optional... If this is how std::optional worked, hardly anyone would use it.

winter_squirrel 5y ago
Why, other languages that require unwrapping it still see plenty of people using optional. In fact, I would have more inclination to use it in my projects if that was the only way to do it.
kentonv 5y ago
> If this is how std::optional worked, hardly anyone would use it. OK... Well, this is how kj::Maybe works and having written several hundred thousand lines of code using it, I think it works well. https://github.com/capnproto/capnproto/blob/master/kjdoc/tour.md#maybes https://github.com/capnproto/capnproto/blob/master/kjdoc/tou...
- kllrnohj 5y ago
  Well, that seems to be using macros to cover up the syntax, which of course the C++ committee isn't going to recommend or use for anything new (nor should they). The actual implementation of Maybe doesn't seem to force anything, it just returns a pointer to the stored value. There's no enforcement of any kind that anything is checked as a result. There's some hoop-jumping with friend classes to "hide" the readMaybe() function to make the non-macro usage as ugly as possible to strongly encourage using the macro-convention, but that's hardly "enforcement". It's a cute syntax & macro pattern, but it's hardly a good fit for a C++ standard, either.
  - kentonv 5y ago
    The C++ committee could come up with actual syntax for this so it doesn't need macros. > There's no enforcement of any kind that anything is checked as a result. There's some hoop-jumping with friend classes to "hide" the readMaybe() function to make the non-macro usage as ugly as possible to strongly encourage using the macro-convention, but that's hardly "enforcement". Sure fine. Anyone who wants to reach into the internal APIs could also just as easily do `#define private public` and bypass every protection C++ has. We're not trying to defend against malicious developers here.
brandmeyer 5y ago
To be fair, languages which require explicit unwrapping also provide syntactic short-hands for the most common idioms. Long-handed if/else (or pattern matching) is used to implement the short-hands or as a last resort. See also value_or and the C++20 monadic methods on std::optional. http://open-std.org/JTC1/SC22/WG21/docs/papers/2021/p0798r6.html http://open-std.org/JTC1/SC22/WG21/docs/papers/2021/p0798r6....
kamray23 5y ago
that is how it works everywhere else and that is how it is used everywhere else
- jcelerier 5y ago
  how is that an argument ? If I was fine with how any other language does things (and $deity knows I've tried a lot) I would not be using c++
  - chupkarkhotay 5y ago
    there's no cure for poor taste

nwallin 5y ago

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

colejohnson66 5y ago

> Note the original title is: T* makes for a poor optional<T&> > The last `<T&>` there is key, but seems to have been removed from the HN version of the title. HN seems to like stripping out HTML-tag-like blocks instead of escaping them. Why though?