Overloaded `Add` on Option has arguably the wrong behavior

[bstrie]

A while ago I overloaded Add on Option types such that Some(1) + None == Some(1). I've since had a change of heart and believe that instead it should be Some(1) + None == None. An informal poll in IRC seems to agree.

[brson]

+1

[isaacaggrey]

Is there any precedence of this behavior from other programming languages (e.g., Haskell, Scala, Standard ML)?

I'm not very familiar with type theory, so my novice eyes see the original behavior as correct; ultimately, I would err on the side of whatever has proven best in other languages (especially as that seems to be Rust's philosophy).

[thestinger]

AFAIK other languages don't define + for their Option types. They have you use map/fmap with any generic function.

It's not very generic right now because it assumes that copying is the behaviour you want when one of the two is None. I would prefer just using higher-order functions to keep the behaviour clear and the API small. Are we going to add the other operators and functions in the standard library? It feels very wrong to me.

Defining Eq/Ord has precedent in other languages and allows for deriving and containers to work well.

Does it really make sense to pass Option<int> to a generic math function making use of Add/Mul?

[catamorphism]

I think that by analogy with the Maybe monad in Haskell, it would make sense for Some(1) + None == None. The intuition is that None represents an error, so once you see an error, you want to propagate it outwards.

I'm neutral about whether we want to have an instance for Add on Option at all. Other languages don't have it AFAIK, but then, Haskell does support using monadic syntax to simplify code that passes around Options, and we don't.

[bstrie]

@thestinger you're welcome to remove it if you think it's a poor idea. My primary concern is that increasing the friction required to make use of Options will simply result in them not being used at all. And since users can't implement this themselves, this is a decision that we have to make now.

[kud1ing]

@catamorphism: Haskell's typeclass MonadPlus shows Rust's current behaviour: mplus (Just 1) Nothing gives Just 1

http://www.haskell.org/haskellwiki/MonadPlus

[catamorphism]

@kud1ing I guess I was thinking of the Maybe instance of the >>= (bind) operator in Haskell.

[kud1ing]

I think we have to decide, whether None means "no value" or "error".
For example: what would be the sum of a list of Options, when there is a single None?

I think we need to support both representations:

• "no value" represented by Option's None
• "error" represented by
  Result's Err.

Whatever we come up with, we should explain the decision at least in the code.

[thestinger]

I don't think there's anything to decide, "no value" and "error" are the same thing if there's only one error that could happen and it means a value couldn't be returned. If there's more than one possible error and there's a meaningful distinction between them that the caller would care about, it should use Result.

An Option<T> return on from_str or a decompression function means "invalid input". An expanded form could return Result and indicate why it was invalid, but both are sane functions.

[huonw]

@kud1ing MonadPlus is slightly different, since mplus (Just 1) (Just 2) == Just 1 (not Just 3), i.e. it is the same as Option::or in Rust.

[kud1ing]

Ask two persons how many pair of shoes they own. One does not reply, the other says 10.
Now calculate the number of pair of shoes people own. Do you say "this is an error, one value is not available" or do you mean "just add the available numbers"?

[catamorphism]

I get where you're going with this, @kud1ing , but I don't think this question has a single right answer. The team just needs to agree on something and document it.

[kud1ing]

@catamorphism: That's why i think we have to be aware of what we want to express and write that down. First so that users know what behaviour to expect and second so we don't change our implementation again and again.

[huonw]

Two questions: Which behaviour is most common? Which is most annoying to implement in "userspace"?

[kud1ing]

I think Option can be seen as a Monoid: http://en.wikipedia.org/wiki/Monoid with the operation "addition".

None would be the Identity element, or empty set.