[topspin]

Agreed. Good site.

This is an aside, and I sincerely apologize for that, but I am compelled...

I'm reading the greeting/hello-world example on this nice site and I notice unwrap_or(). That is a poor name: can it panic, as suggested by the "unwrap" part (I have just enough Rust to know that,) or can it not, as suggested by the "or" part? The name is inherently ambiguous!

It's as if the .unwrap() that is festooned throughout such example Rust code has become so ubiquitous that someone felt it had to be used and so tacked on "_or". Why couldn't it just be .or() or perhaps .default()?

And so I investigate and things go rapidly downhill from there. Consider:

    unwrap
    unwrap_or
    unwrap_or_else
    unwrap_or_default
    or
    or_else

Good grief. The word ambiguous seems inadequate to describe what has emerged here.

Again I'm sorry; this is clearly off topic, probably badly naive and possibly inappropriate in a few other ways to which I'm pathetically oblivious. I couldn't help myself.

[steveklabnik]

"unwrap" doesn't mean "panic". It means "to take out of some kind of container". So, the question is, what to do if the thing isn't in the container?

    unwrap: panic
    unwrap_or: produce this value instead
    unwrap_or_else: produce a value by running this closure instead
    unwrap_or_default: produce a default value instead

or and or_else are just like unwrap_or and unwrap_or_else, but they don't do the unwrapping; you keep the container.

In this case, the "container" is option, but similar types have the same methods, like Result.

> Why couldn't it just be .or() or perhaps .default()?

or returns Option<T>, unwrap_or returns T. .default returns the default value for a T already.

TL;DR: you have a lot of options (pun intended, sorry!) with what to do, but the names all follow a quite regular scheme.

[dbaupp]

The "unwrap" is referring to getting a plain T out of a Foo<T> container: all of those "unwrap" functions return a plain T.

One way to look at them is "unwrap", "or" and "or_else" are building blocks that have a common meaning across the different examples:

- unwrap: returns a plain T

- or: the left-hand side, unless it is a "failure", then use the argument value

- or_else: the left-hand side, unless it is a "failure", then use the argument function to create the value

[masklinn]

For prefixes, unwrap mean Option<T> -> T while or means Option<T> -> Option<T>[0].

For suffixes, "else" means executable code (a closure).

> > It's as if the .unwrap() that is festooned throughout such example Rust code has become so ubiquitous that someone felt it had to be used and so tacked on "_or". Why couldn't it just be .or() or perhaps .default()?

Because Rust doesn't have function overloading and thus you'd be missing most of the cases?

[0] or more generally Wrapper<T> -> T and Wrapper<T> -> Wrapper<T>

[topspin]

>> Because Rust doesn't have function overloading

That is the insight I needed. Thank you.

Rust seems novel in that despite having powerful abstractions and a rigorous type system it does not support overloaded functions. I gather from some of the discussions about it that this design decision greatly simplifies the compiler implementation; supporting function overloading would necessitate answering several very tough questions such as whether a function can be overloaded on argument lifetime.

So the Rust standard library has established conventions (in this case 'unwrap', 'else' and or 'combined' in various ways) to deal with the permutations that naturally emerge given the lack of function overloading. It's important understand this and inculcate these conventions, particularly when designing interfaces for use by others.

[masklinn]

> Rust seems novel in that despite having powerful abstractions and a rigorous type system it does not support overloaded functions.

Neither Haskell nor ML (incl. its children) have function overloading.

[malcolmgreaves]

Learn about the Option type: https://en.wikipedia.org/wiki/Option_type