Deprecate unwrap in favor of more meaningful method namess

language design
1

For both Option and Result, unwrap() really is a misnomer IMO. First off, they shouldn't both be called the same thing.

"expect()" on the other hand is very meaningful, and very well named. But let's get back to unwrap(). For the Option scenario, it does kind of make some sense, but also kind of not. You might have something (a Some) you can unwrap or you might have none which there's nothing to unwrap cause it's none. I'm just talking the "non technical" thought process related to this. We simply can't unwrap a None - it's a None (and so yes, I get that this panics ..., but it also just doesn't "read well"). For option, I'd go with "get_some_val()" (or something like that) Something like "get_ok_val()" would be best for Result.

The "?" operator is great. When clicking on variant names in documentation for enums, it might be helpful to include "this is not a type, just an enum variant" because, while this is "Rust 101", it's easy to not "see" because you're looking at types all day, and it just looks like another type.

You'd be surprised how much THIS is the stuff that trips people up including myself. Takes a long time not to "talk stupid" coming up on rust ...

All this made me think of a possible language feature which is "function/method aliasing". The idea is to simply be able to refer to any method by another name (be it internal or a third party library). Instead of another function (renamed) that calls into the one that has the name you don't prefer, it's a compile time feature that simply replaces it pre-compilation with the actual method name (ie, zero cost).

My guess is that people that come from languages that have ADT pick up Rust in no time. If never used them before, long time ...

2

It would be way too much churn to deprecated unwrap now. There's a clippy lint if you want to ban it in your own code bases.

An ecosystem where every enclave invents their own conventions to rename fundamental methods to something they prefer sounds much worse to me than adhering to a universal name, even if that name is flawed.

It's a tuple variant of the Option type. The constructor is in the prelude, which is why you can use it directly. You can do the same for your own enums.

You can't define ? for your own types on stable yet, but here's the tracking issue.

6 Likes
3

Thanks, I don't know what I was thinking regarding Some.

Algebraic Data Types are also a place where people like me "don't see it" easily. I do see now that I was reading variant type as a an actual type, but in code it seems that way.

Perhaps this is an area of the "upfront" training should be focused since it's such an "Enum Centric Language", but you don't necessarily see it right away so most coming from languages that don't have algebraic data types don't "process it". It's the biggest mental hurdle coming from typical OO languages that don't have enums that hold data. It's more of a mental hurdle that I originally thought.

1 Like
4

If you have any idea on how to explain it better, please open issues or PRs to the relevant training materials (maybe the Rust book). It’s unfortunately one of those area that are hard to understand, but once you understand them you don’t even remember what was hard about it.

5

It's too late to change it. It's everywhere in examples, docs, and books. Rust is meant to be stable now, and not cause unnecessary churn.

Even if you just add a new method, that will cause a ton of questions what's the difference between them and which one should be used.

Unwrap already has replacements ?, map, if let, etc. so there's no need to add a better function that you shouldn't be using anyway.

4 Likes
6

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