T* makes for a poor optional&lt;T&&gt;

Re:T* makes for a poor optional<T&> by strager on Monday December 13, 2021 @03:46PM (#29544423)

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

[ Parent | on HN ]

Re:T* makes for a poor optional<T&> by kentonv on Monday December 13, 2021 @05:23PM (#29545452)

> 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/tou...

[ Parent | on HN ]

Re:T* makes for a poor optional<T&> by kllrnohj on Monday December 13, 2021 @05:44PM (#29545665)

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.

[ Parent | on HN ]

Re:T* makes for a poor optional<T&> by kentonv on Monday December 13, 2021 @09:38PM (#29547541)

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.

[ Parent | on HN ]

Re:T* makes for a poor optional<T&> by brandmeyer on Monday December 13, 2021 @05:47PM (#29545694)

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

[ Parent | on HN ]

Re:T* makes for a poor optional<T&> by kamray23 on Monday December 13, 2021 @05:58PM (#29545807)

that is how it works everywhere else and that is how it is used everywhere else

[ Parent | on HN ]

Re:T* makes for a poor optional<T&> by jcelerier on Monday December 13, 2021 @08:02PM (#29546872)

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++

[ Parent | on HN ]

Re:T* makes for a poor optional<T&> by winter_squirrel on Monday December 13, 2021 @04:13PM (#29544718)

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.

[ Parent | on HN ]