`Option.map_or_else` arguments in the wrong order?

libs
1

I really feel like the arguments are in the wrong order for Option.

API: https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.map_or_else

I would expect that the first argument for map_or_else is the map function and the second be the “else” but that’s actually the opposite. I always felt weird about it and today a colleague was also confused about it (which made me realize I am not crazy :slight_smile: )

I could make the same comment about map_or.

Obviously it’s too late to fix but does anyone has an explanation?

2 Likes
2

I suspect for map_or the reasoning was “let’s get the short default arg out of the way before the potentially long closure”. It’s pretty hard to find the former otherwise.

map_or_else then just follows for consistency.

6 Likes
3
4

This has already been discussed.

1 Like
5

deprecate those and add map_and_unwrap_or_else which follows the same argument order as the call order? (map followed by unwrap_or_else)

this is what A/B testing is meant to solve.

6

How are you proposing to A/B test a standard library?

2 Likes
7

Add both variants and use a feature flag to select which.

Not sure how to compile this. I’m not proposing an implementation.

The feature flag most used is the preferred one.

8

A/B testing on the web works because you can present both A and B to users, and then silently switch between them and to the winning one in the future.

In the compiler, this model doesn’t work. The already stable format has “won”, so to speak; it’s stable and doesn’t require opt-in, and will always be there.

If you want to discuss the possibility of A/B testing, feel free to make a new thread about it, but this thread isn’t the place to discuss it. (I’d recommend picking one proposal you care about and sticking to it, though, rather than drag other threads to your dozen-or-so vague directions every time they say something remotely related.)

1 Like
9

It’s still possible to deprecate+replace this. Actually that’ll always be possible.

And then we can A/B test the replacement.

10

IMO A/B testing isn’t necessary, the point has already been demonstrated… Other language (like scala) which have a very similar syntax, the same option type but don’t have those method, has never received a complaint about it as far as I am aware. On the other side, Rust is newer and those methods already have several complaints on their records which kind of demonstrate that they don’t bring much value and just add confusion.

If i had to change, i would just gzt rid of it as it’s just a short cut for something which is not painful IMO.

Too late now though… Deprecating it would lead to a flame war that no one wants, lets just embrace it …

11

Deprecation and #[doc(hidden)] would still prevent future arguing. Over time, ppl would just forget it ever existed.

12

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.