You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering would adding a few more methods to some of the containers would help with productivity.
For example:
auto o = fplus::maybe<int>(1);
auto p = fwd::apply(
o,
fwd::and_then_maybe([](auto x) { return x > 0 ? fplus::just(1) : fplus::nothing<int>(); }),
fwd::lift_maybe([](auto x) { return x * 2; }),
fwd::just_with_default(42)
);
auto p2 = o
.and_then([](auto x) { return x > 0 ? fplus::just(1) : fplus::nothing<int>(); })
.lift([](auto x) { return x * 2; })
.get_with_default(42);
That way:
It aligns with the C++23 monadic interfaces on optional
We can drop the _maybe suffix as it's clear based on the method receiver
We should still keep the free functions but those simply delegates to the instance implementation, so we don't need to
forward declare it or do anything awkward.
For most cases (e.g chaining on the same functor), we can get the same effect of using fwd but without the extra boilerplate.
I'm happy to open a PR if we think this is a good idea.
The text was updated successfully, but these errors were encountered:
Oh, that looks like a splendid idea to me in terms of code readability. ❤️
Yeah, we should keep the free functions (to not break old client code). And, I agree, letting the free functions forward to the member functions (instead of the other way around) is the way to go, exactly because of the reason you mentioned. 👍
I was wondering would adding a few more methods to some of the containers would help with productivity.
For example:
That way:
_maybe
suffix as it's clear based on the method receiverforward declare it or do anything awkward.
I'm happy to open a PR if we think this is a good idea.
The text was updated successfully, but these errors were encountered: