Maybe data type alternative to Option.

[lvicentesanchez]

Should cats include the Maybe data type as an alternative to Option?

[stephenjudkins]

Does scala.Option have any obvious deficiencies like scala.Either?

[lvicentesanchez]

The most obvious to me is the get method that can raise an Exception if your Option variable contains a None.

[mpilquist]

• The unsafe get method.
• Unnecessary boxing -- a value class that represents None as null at runtime, and hence disallows Some(null).

Not convinced this belongs in cats though.

[non]

Agreed. The value class idea is nice, but it isn't really an Option[_] replacement since it can't represent Option[Option[_]].

[tpolecat]

There's also the implicit conversion to Iterable, which can be a source of suffering. The zip method is particularly fantastic.

So I think Maybe would be nice to have, but in practice I think Scala developers learn what to avoid with Option and don't get tripped up very often. I do lean toward including these things in cats eventually, but I am in the minority and won't argue loudly. For now I certainly agree that finishing up the core typeclasses and clearly missing/broken data types should be the priority.

[rossabaker]

I'm wary of trading the network effects of stdlib for these modest improvements. I would still rather cats.data is for complementing stdlib and some other place for replacing it. (See also: collections.)

[adelbertc]

I'm OK with things like IList and Maybe existing and often time I will reach for them (quickly) for my own projects, but when working with existing code (e.g. at $JOB) where everyone else is using List and Option I'd still like to use cats without having to deal with stdlib types and cats equivalent. I suppose what this boils down to is for outside-facing things, say some stream iteration function, I'd rather see B => Option[(A, B)] => Stream[A] as opposed to B => Maybe[(A, B)] => Stream[A].

That being said I happily reach for Or as an exception to this rule since the stdlib Either is....... weird.

[lvicentesanchez]

I agree that adding Maybe as a replacement for Option has less value than adding Or as replacement for Either and I totally agree that this should not go to cats.data.

[stew]

My gut feeling is that this stuff belongs in a separate project.

[mdedetrich]

Throwing my own opinion in here, which pretty much echoes most people here

I feel very little benefit in cats having a Maybe type. Just because Option happens to have a single unsafe method, and that its an Iterable are very weak reasons. The boxing is a more legitimate concern, however something like miniboxing is the right approach there.

I think one of the things to learn from Scalaz is to not overbuild the entire stdlib just because everything isn't 100% "pure". Scalaz also had a Maybe type, which practically no one used. Then there is even worse stuff like IList, which had severe performance characteristics in some situations (this is probably due to the fact that it wasn't as battle tested as stdlibs List)

If people wan't to add Maybe as another module, I am fine with that, however I think we need to be generally careful in not unnecessarily fragmenting the experience of users, which means keeping the core as clean and as small as possible (and I believe this is one of the design goals of cats)

[ceedubs]

It sounds like the decision is to stick with Option. If someone really wants Maybe, it could live in its own project. I'm going to go ahead and close this.

[mdedetrich]

Also on the note regarding boxing (in response to @mpilquist), you can use name based extractors to avoid the boxing for Option, i.e. check http://hseeberger.github.io/blog/2013/10/04/name-based-extractors-in-scala-2-dot-11/. I learnt this trick when writing a new JSON library