Closed tom91136 closed 9 months ago
That looks splendid! Working with Maybe
types is much more convenient that way. :heart_eyes:
The only potential downside of the member functions over the free functions might be the auto
return type on some. However, adding an explicit return type could be quite complex with the derivation based on the passed F
, etc. So let's keep it that way (with auto
). In case some users don't like it because the auto-completion in their IDE does not play too well with this, they can still use the free functions (which have explicit return types). :white_check_mark:
A
just_if
method (e.gfilterM
for our maybe functor) which I believe is missing.
That's a very nice addition! :rocket:
Moved
is_maybe
frominternal
to top-level as we need this for join, and I also think this is a very useful API to expose.
Since we don't expose such helpers in other parts of the library, I'm not yet sure about exposing is_maybe
to the fplus
namespace here. .join
(and
.and_then
) could also use is_maybe
if is_maybe
would still be defined in internal
(at the same location in the file, i.e., above the class definition). :thinking:
Sure, I've reverted that part.
Cool. :+1:
And, thanks a lot for this awesome contribution! :heart:
This PR implements #288.
I've added new checks directly below the existing maybe tests to make sure it compiles. An extra test on chaining the fluent interface is also included, we can now do:
I've made the following additions to the API:
just_if
method (e.gfilterM
for our maybe functor) which I believe is missing.is_maybe
frominternal
to top-level as we need this for join, and I also think this is a very useful API to expose.