On 11/01/2013 08:30 PM, Alex Crichton wrote:
# Renaming `unwrap` to `get`
I would personally find this change a little odd because we still have
a large number of `unwrap` methods thorughout the codebase. Most of
these do indeed imply destruction of the enclosing type. A change like
this would mean that when you decide to write your unwrapping method
you must internally think about whether this always implies that the
outer type would be destroyed or not. In my opinion, unwrap() on
Option<int> does exactly what it should and it's just a bug vs state
of mind kind of thing. I would rather strive for consistency across
all APIs than have a special case based on whether the type just
happens to not be destroyed because the whole thing is implicitly
copyable.
Imo we still keep consistency even with this rename. `get` is simply the
more general term which we'd use for generic situations where we don't
know anything about the type, while specific implementations can choose
either name depending on situation.
I think it's more useful to say "use the name unwrap if the function
does something non-trivial". For example, `ARC::unwrap()` should
probably not be renamed to `get` because it can block the task.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
