`map` seems to be more like `map_or_else` about bool_ext HOT 3 CLOSED

Agreed, in principle.

• I'm not sure I see the value of map_or_default given map_or, though.
• map would also need to be added, as would the lazy versions of these combinators.
• Are you aware of the rationale for map_or taking its final parameter as a function, rather than being fully eager?

from bool_ext.

These are basically copy pasted from the set that std has for Option

• map_or_default exists, (and can be useful, presumably for similar usecases as Option::None.map_or_default)
• I'm not sure what map by itself would do in this context, as it doesn't make much sense on a type that isn't a container
• Given the suggestion to rename map to map_or_else, map_or would produce default if self == false and f() if self == true, this reflects Option where we basically have a family, where or means "use the given value if we're None" or_else means "compute the function if we're None" and "map" means "compute a transformation if we're Some", given an assumption of mapping of true to Some(()) and false to None, that would mean that map_or would want to compute a value if self == true (if it didn't, we'd just have unwrap or but with reversed arguments)

from bool_ext.

I like the transformations around map (map->map_or_else + map_or and map_or_default) and will implement these for v0.4.
Re: the unwrap methods--it is not a goal to turn the bool API into a mirror of Option, so I think the existing expect method (combined with the expectation that the user will negate the value if they wish to panic on true instead of false) should be sufficient. I also like that expect doesn't carry the connotation of unwrapping, given that, as you point out, bool is not a container.
Thanks again, I very much appreciate you sharing your thoughts on this API!

from bool_ext.