Option<T> `map_or` and `map_or_else` type is inconsistent with `map`

[FuGangqiang]

map method type is

fn map<U, F>(self, f: F) -> Option<U> 
    where F: FnOnce(T) -> U

map_or method type is

fn map_or<U, F>(self, default: U, f: F) -> U 
    where F: FnOnce(T) -> U

map_or_else method type is

fn map_or_else<U, D, F>(self, default: D, f: F) -> U 
    where D: FnOnce() -> U, F: FnOnce(T) -> U

map : Option<T> -> Option<U> is ok,
but map_or and map_or_else : Option<T>->U ,why not return Option<U> type

[abonander]

What use would it be to return Option<U> if you know it's always going to be Some(U)? Both map_or and map_or_else are given a default to return if self is None. Their design parallels unwrap_or() and unwrap_or_else().

[alexcrichton]

Yes as @cybergeek94 these are just shorthands for .map(...).unwrap_or(...), so the signatures aren't exactly in alignment. These functions are also stable today, so their signatures won't be changing.