> I really like Common Lisp's solution because it doesn't force boilerplate on you.
Checking what needs to be checked is not boilerplate.
> If you care whether or not the key was present, the second return value is there and, otherwise, you just continue on your way.
Which is the entire issue. By default, if you're not careful or don't check, you just get garbage without warning.
> Also, since MRVs are a language construct, you can abstract over them
No, MRV being a language construct does not allow that at all (you can't do any such thing in Go because MRVs are language structures rather than properly reified). You can abstract over MRVs in CL despite them being MRVs, because CL specifically provides a bunch of dedicated constructs for working with MRVs.
> So, I'm not really sure there's a decisive advantage of Options vs. the MRV solution.
That options force the developer to deal with the issue and do so by default.
> In fact, if you change your perspective a bit, Options (and possibly sum types in general) are just ways of getting multiple return values in languages that only support single return values
Utter nonsense, MRVs are products. The entire point of sum types is that they're not, their purpose is to provide alternatives in a type-safe manner. The way to get multiple return values in "languages that only support single return values" is tuples.
> you could think of the case of the sum type (i.e. "Some" or "None" being one of the return values and the wrapped value(s) being another.
> No, MRV being a language construct does not allow that at all (you can't do any such thing in Go because MRVs are language structures rather than properly reified).
Oops, I meant "because MRVs are a first-class language construct in CL (if only because of macros), you can abstract over them ..."
Secondly, tagged unions are a very standard way of simulating sum types in languages that lack them. All I was saying is that MRVs can be used in a similar way. E.g., an option can be replaced by a pair of values, one of which indicates whether or not the value is present and the other indicates what the value was.
As far as the boilerplate issue goes, if you really need to make sure that a field is present, you should be using hash tables in CL, you use a class and when you try to access an unbound slot, it throws.
Finally, it's just wrong to say that Options are only useful in statically typed languages: any _strongly_ typed language can use them effectively, whether or not those types are checked at run time or compile time.
Checking what needs to be checked is not boilerplate.
> If you care whether or not the key was present, the second return value is there and, otherwise, you just continue on your way.
Which is the entire issue. By default, if you're not careful or don't check, you just get garbage without warning.
> Also, since MRVs are a language construct, you can abstract over them
No, MRV being a language construct does not allow that at all (you can't do any such thing in Go because MRVs are language structures rather than properly reified). You can abstract over MRVs in CL despite them being MRVs, because CL specifically provides a bunch of dedicated constructs for working with MRVs.
> So, I'm not really sure there's a decisive advantage of Options vs. the MRV solution.
That options force the developer to deal with the issue and do so by default.
> In fact, if you change your perspective a bit, Options (and possibly sum types in general) are just ways of getting multiple return values in languages that only support single return values
Utter nonsense, MRVs are products. The entire point of sum types is that they're not, their purpose is to provide alternatives in a type-safe manner. The way to get multiple return values in "languages that only support single return values" is tuples.
> you could think of the case of the sum type (i.e. "Some" or "None" being one of the return values and the wrapped value(s) being another.
You really could not, that's the entire point.