[gavinpc]

> When have you ever had to unnecessarily break API compatibility because something you thought was an Option[T] result turned out to be really a T, always?

That would be a breaking change. And should be, if you're into that sort of thing.

The objection is to the opposite case: What was a T is now an Option[T]. I don't know Scala specifically, but that's a breaking change in every typechecked language I know. Rich is arguing that it shouldn't be. But it could be possible even in typed languages through union types. For example, you can do this in TypeScript by changing T to T | undefined, which is a superset of T.

[patrec]

Nope, it's not the opposite case, I was just to lazy to spell it out. Which way around it is depends on whether it's a return value or parameter. Covariant vs contravariant. If it's a parameter an API change from T to Option[T] shouldn't break (you require less), whereas with a return type it's from Option[T] to T (you promise more).

[gr__or]

To be fair the "result"-part in "something you thought was an Option[T] result turned out to be really a T" makes it sound like you were speaking of the return-type to me as well. I appreciate the elboration though!

[gavinpc]

Yes, that was my fault, I overlooked "result," and I also appreciate the clarification.

I think the point remains that, while this is not a breaking change from a contractual viewpoint, most type systems would deem it incompatible.