4 ms·

> 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

> 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

> 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