Repository navigation
Tracking issue for Cow::is_borrowed and Cow::is_owned #65143
Description
I just tried to use these in my own code and was kind of shocked they didn't exist.
Justification: this seems like a common Rust pattern. We have is_some and is_none for Option, is_ok and is_err for Result, etc., so, it seems pretty fair to have is_borrowed and is_owned for Cow.
Having as_borrowed and as_owned wouldn't really make much sense, as a simple & and &mut/to_mut cover those use cases. But, these check functions are pretty useful on their own.
Unresolved question: do we want to ship these or defer to matches! and the future possibility of is?
Reacted by Charles Lew, DutchGhost, Lucas, Tim Hutt, Clément Renault, Dan Kolsoi, Stanislav Tkach, Eduardo Pinho, Denis Kotlyarov, Colin Woodbury and 32 more
Reacted by George Bateman
Reacted by Denis Kotlyarov, Pop, Felipe S. S. Schneider, Trevin Miller, Iago-lito, dzmitry-lahoda, Timon Klinkert and widberg
Activity
[-]Cow::is_borrowed and Cow::is_owned[/-][+]Tracking issue: Cow::is_borrowed and Cow::is_owned[/+]petertodd commentedon Oct 12, 2019
I'm no expert on how backwards compatibility is handled. But
CowimplementsDeref, which means these new methods wouldn't be backwards compatible as they'd conflict with methods of the same name on the inner object. To fix this you'll have to change them to takecow: &Self, similar to what most of the methods onBox/Rcetc. take.[-]Tracking issue: Cow::is_borrowed and Cow::is_owned[/-][+]Feature request: Cow::is_borrowed and Cow::is_owned[/+]SimonSapin commentedon Oct 18, 2019
Procedural: I’ve edited the title and labels to reflect that this is not implemented.
My opinion: I’m not sure that these method carry their weight, since
if let Cow::Borrowed(_) = fooormatches!(foo, Cow::Borrowed(_))can be used. Neither of these existed whenOption::is_somewas added, andOptionis much more common thanCow.clarfonthey commentedon Oct 22, 2019
@petertodd That's fair; that said, though, I think that having methods named
is_borrowedoris_ownedon a type which implementsToOwnedwould be extremely unusual, becauseto_ownedwould not affect said methods.@SimonSapin I agree that
Optionis much more common thanCow, but I feel that these are still useful enough to carry their own weight. This is partially because I was writing code and was honestly surprised they didn't exist, so, I'm already pre-biased to assume that they should exist.Mostly, I figured that adding these methods would be worthwhile because they're unlikely to clash with existing ones, and can incubate in nightly for a while to see if they do carry their weight. If they don't, they can be removed.
Rollup merge of rust-lang#65144 - clarfon:moo, r=sfackler
clarfonthey commentedon Oct 23, 2019
It appears that this is now merged.
27 remaining items
Rollup merge of rust-lang#131617 - RalfJung:const_cow_is_borrowed, r=…
Rollup merge of rust-lang#131617 - RalfJung:const_cow_is_borrowed, r=…
Unrolled build for rust-lang#131617
scovich commentedon Nov 4, 2024
+1 from me here -- every time I've tried to use
matches!in the past (for any reason), reviewers complain that it's hard to read and ask if there's way to avoid it.As long as this feature isn't stable, I just end up injecting the methods with an extension trait for readability purposes.
BartMassey commentedon Jan 30, 2025
I was quite surprised that these were not available on stable. +1 for stabilizing them:
matches!()is a poorer alternative in my opinion, being hard to read and write. I don't understand the downside at all, I think?GKFX commentedon Feb 2, 2025
@BartMassey My concern is that determining which variant of an enum a variable is should be a clear and easy application of pattern-matching. Pattern-matching is a crucial Rust feature, and if a simple example of it is considered so verbose or cryptic that it has to be wrapped in a helper function, then to me it demonstrates a need for something like the
iskeyword to make it more accessible (rust-lang/rfcs#3573), rather than creating helper functions to work around the problem.As for other
is_*methods in the standard library:is_ge). This makes sense for that type.is_ok/is_err/is_some/is_none, and I personally would like to drop the Clippy lint that advertises them, particularly if theiskeyword passes its RFC.BartMassey commentedon Feb 2, 2025
@GKFX I understand that the prior art is complicated, and that we are planning better features for the future.
That said, this five-year-old issue (opened before
matchesexisted) asks to add a couple of convenience methods that do not get in the way of anything, require zero maintenance, satisfy the expectations of many existing users including myself, are simple to implement, understand, use and document. Let's just stabilize them.It seems to me that
std::borrow::Cowis less-used than it could reasonably be. I think this is at least partly because it presents an unfamiliar minimalist interface that is hard to understand. I avoided teaching it in my intro Rust classes for many years for this reason. This change is a step in the right direction.(As for Clippy, I strongly prefer that it not take positions on choices that could reasonably be made multiple ways — but that's a separate issue.)
hkBst commentedon Mar 9, 2025
#138217 moves these to associated functions, but also reveals that there is only one single use of
Cow::is_ownedand none of is_borrowed within core/alloc/std. (Otherwise those uses would also have needed adjusting to the change.)If I saw correctly these were introduced in October 2019?
Rollup merge of rust-lang#138217 - theemathas:cow_is_owned_borrowed_a…
Rollup merge of rust-lang#138217 - theemathas:cow_is_owned_borrowed_a…
Unrolled build for #138217
Rollup merge of rust-lang#138217 - theemathas:cow_is_owned_borrowed_a…