> to behave in such a way that it inserts a suitable “empty” value for whatever type the option is guarding. Some types have no suitable "empty" value. It is d

> to behave in such a way that it inserts a suitable “empty” value for whatever type the option is guarding. Some types have no suitable "empty" value. It is dangerous to assume you can always find such a value. In essence, when you're expecting that such a value exists, you're implicitly relying on your type being a suitable monoid. That's fine when you're expecting this and when it is actually a monoid, but not all types are. > In practice, you’d instead write code to provide that empty collection at the call site. Not all types can be modelled as collections. This is the same problem as above. What I'd actually do is either: 1. Fail the parent operation by again using `?`, or 2. Provide a suitable default/"empty" type, if it is possible to continue. It's very important that such a decision is explicit on a case-by-case basis, and this is what `?` allows you to easily do without much fluff or noise. > At this point you’ve rendered the Option wrapper pointless though. How was it useless? It allowed us to safely write a procedure as if the value existed and otherwise cheaply signal failure to the caller. The caller can then repeat the same process. What's important is that the procedure stands on its own and is safe out of the box. It clearly says that it can fail (by returning an option) and we know exactly when it has failed and when it has not. > You’ve given a different behaviour which is of course, a logic bug. I don't see where the bug is?