Comment by louthy | Hacker News Reader

Comment by louthy | Hacker News Reader

Parent Full thread

I hear what you're saying, but I felt that the reason for using Option in C# would be explicitly to deny nulls. If you are OK with accepting null, don't use Option and return null.

I think that's slightly different with F# where you mostly deal with value types that definitely have values. It's rare that you need to pull null out of the bag (unless interop'ing with .NET libs).

I understand why you might call it a bug, but I think I make the reasoning clear in the documentation. So I hope it's unlikely to cause confusion.

The proper way to do this is to have something like in Scala where you say

    Option(foo)

if you want "foo" coerced to either Some(...) or None based on its nullity. It doesn't prevent you from using

    Some(null)

if that's what you really mean. (Though I think it might be a reasonable idea to actually throw an error in such a case. However, there should be a way to construct a Some(null), perhaps with a name that suggests that it's not recommended. Perhaps something with "unsafe" or "unguarded" in the name.)

> Perhaps something with "unsafe" or "unguarded" in the name.

That seems like a reasonable approach.

I feel like throwing a NullReferenceException would be the more appropriate way to deal with it. Either treat Some(null) as a valid value, or treat it as an error. Silently coercing it will lead to problems down the line, like with the Some(Some(null)) case mentioned.

I'm definitely starting to lean that way. Thanks for the feedback.

Reply on news.ycombinator.com