Jon Pretty

Stop using, opt match { case Some(x) => f(x); case None => y } Stop using, http://opt.map (f).getOrElse(y) Use, opt.fold(y)(f) I feel like I'm very late to this party.

I actually kind of disagree. map(f).getOrElse(y) clearly conveys the intent of your code and makes it easy to understand for other people. fold(y)(f) doesn't. In my case at least, I always have to do the mental gymnastic of "oh, this means map.getOrElse"

But wouldn't you say that map...getOrElse is itself halfway between the pattern-match to the fold in terms of clarity? I think the difference is that right now we're much more familiar with maps than folds, especially when the context is an Option.

Honest question though: is that a proper fold? In my mind, fold is heavily linked to monoids: - takes an "empty" value - takes a merge function that's basically a monoidal append This is not what Option.fold does. Am I misunderstanding what fold is?

Your mixing `Foldable` (the typeclass) with the algebraic fold, the later is basically isomorphic to pattern matching. The fact that folding on a List is recursive, is incidental (because the type itself is recursive), not the opposite.

Ah. So then, on the one hand it makes sense, on the other, I feel it might be a fact in favour of my argument: it might be unreasonable (today) to expect most developers to know about algebraic folds, and map(x).getOrElse(y) *will* be more readable for the majority of them

Well, that is really subjective. It is entirely relate to your familiarity with such concepts and which path you took to learn to code. For example, I don't want my syntax to look like JS/PHP just because it is popular...

I agree when it brings a clear advantage. I don’t see it here - you save a few characters at the cost of making your code less immediately readable to a lot potential readers - but that’s just my perspective.