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

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 ]