I hope the fish operator is the right semantics in here. I think it is when we extend the understanding that KeyPath is just a syntactic sugar for (A) -> B?, which we are flatMapping to (B) -> C?. Then it's a >=> over Optional Monad. Can't think about KeyPath as a Monad itself because I can't create a KeyPath with custom init, it has internal use only in Swift. So thinking about it as a Prism Getter, that composition using >=> would make sense.
Also removed the second variant with a hardcoded C that ignores B, in favour of keyPath >=> (ignore >>> hardcodedDerivedAction), which looks more correct from the composition point-of-view.
The options without custom operator are now public anyway, for those who don't like the chosen custom operators, or any custom operator at all.
I hope the fish operator is the right semantics in here. I think it is when we extend the understanding that KeyPath is just a syntactic sugar for
(A) -> B?
, which we are flatMapping to(B) -> C?
. Then it's a>=>
over Optional Monad. Can't think about KeyPath as a Monad itself because I can't create a KeyPath with custom init, it has internal use only in Swift. So thinking about it as a Prism Getter, that composition using>=>
would make sense.Also removed the second variant with a hardcoded C that ignores B, in favour of
keyPath >=> (ignore >>> hardcodedDerivedAction)
, which looks more correct from the composition point-of-view.The options without custom operator are now public anyway, for those who don't like the chosen custom operators, or any custom operator at all.