Right, but that ignores the fact that I brought up
Monoid because it is actually a sub-optimal solution in many cases, including the motivating examples.
One of the unfortunate aspects of the SE community is the desire to always push off related topics to independent threads. This prevents us from stepping back and looking a the motivating problem more holistically. IMO, this proposal cannot be evaluated well without considering alternative ways to solve the motivating problems, including
I agree with others that if we include a
fold that is not based on
Monoid it should not trap and should return optional. However, I don't think it makes sense to include such a method unless there are sufficiently many use cases that cannot be addressed well with
Monoid. If you want to continue proposing an
fold I recommend looking for use cases other than monoid-style value combining (it might help to look for semigroups that are not also monoids).