|
|
|
|
|
|
by masklinn
2946 days ago
|
|
|
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> |
|
|
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.