Open mqudsi opened 3 years ago
Renaming existing methods in the standard library is, simply, not an attainable goal at this time.
There's not going to be breaking changes in the standard library any time in the foreseeable future.
Is labeling a method deprecated considered a breaking change? I could see that argument going both ways.
It is not, but we are not deprecating remove
. You could add a rustdoc alias to take
for them though.
I think HashSet
has take
because it is the more unusual case and remove
is reserved for the more typical case (if set.remove() { .. }
). But the general convention, I believe, is to use take
for singletons like Option
and use remove
for collections of multiple values.
This is something that threw me off years ago when I spent more time than I'd care to admit looking for a
Collection::take()
when it was actually namedCollection::remove()
, more specifically because I wanted to move an object out of a container (rather than simply remove it from the container) and I was going by what syntax I knew rust used in other places to do just that. Although it's been some years, it occurred to me to file an issue today, although I may have forgotten the exact details of what types I was dealing with at the time (given that this just gets harder the more one waits).I would like to propose that methods returning
T
orOption<T>
rather thanbool
should be namedFoo::take()
rather thanFoo::remove()
. This would apply to, among others,VecDeque::remove()
,LinkedList::remove()
,HashMap::remove()
,HashMap::remove_entry()
,btree_map::OccupiedEntry
,hash_map::RawOccupiedEntryMut::remove()
,hash_map::RawOccupiedEntryMut::remove_entry()
,Vec::remove()
, and (somewhat contentiously, but only if you don't primarily think of it as a collection)String::remove()
.Reasons in favor of this change:
1) It is semantically clearer:
.take()
implies both removing something from its current holder/owner ("taking" it away), and gaining ownership of said thing yourself, whereas.remove()
only implies the former and doesn't actually differ (semantically/linguistically) from what we refer to asdrop()
in the rust world. 2) It is more consistent.BTreeSet
andHashSet
already use.take()
and most rust users are introduced toOption<T>
before they ever use collections, where the nomenclature is.take()
and not.remove()
.Option<T>
,std::mem
,Cell
,RefCell
,OnceCell
,SyncOnceCell
all use.take()
to relinquish ownership of an/the item/entry. 3) It is not yet too late, as none of the mentioned types currently use.take()
for anything, so.remove()
could be deprecated without any breaking changes (unless any implementIterator
directly - which I don't think is the case - asstd::iter::Iterator::take()
is a thing)Reasons against:
1) It's a lot of churn.
Possible alternatives:
1) Reserve
.take()
for all these types (i.e. make sure no future method is created with that name) both a) to prevent confusion, and b) so thatrustc
can automatically suggest usingremove()
any time someone mistypes.take()
instead on one of these types.