add maybe concept and maybe_view
#1659
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the original famous Pythagorian Triples blog, there is a
maybe_viewin the example.There was also a proposal to the standard to have
maybe_viewbut there isn't any update on that paperhttp://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1255r6.html
However, I don't agree with paper about the
nullableconcept.First, why don't we call the concept
maybegiven that the view is calledmaybe_view.Second, I don't think it is a good idea to couple
operator boolandoperator *with the concept. In the paper itself, there was already a special casereference_wrapper. In real world use case, I believe there will be lots of types, which can represent a null value withoutoperator *. For example,std::function,std::future,std::variant<std::monostate, Foo, Bar>I think it might be a good idea to create some Customisation Points, which can default to
operator boolandoperator *. Originally the paper had two customisation pointsmaybe_has_valueandmaybe_valuebut they got removed from R0 version, which I can't find the reason forI propose to have two customisation points and support types that can represent null but don't have
operator booloroperator *:is_justandget_justIn this pull request, except the concept, the implementation is pretty much the same as what it was proposed in that paper.
Feedback welcome!