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 `Monoid`

.

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 `Optional`

-returning `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).