Tracking issue for Cow::is_borrowed and Cow::is_owned

[clarfonthey]

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.

[petertodd]

I'm no expert on how backwards compatibility is handled. But Cow implements Deref, 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 take cow: &Self, similar to what most of the methods on Box/Rc etc. take.

[SimonSapin]

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(_) = foo or matches!(foo, Cow::Borrowed(_)) can be used. Neither of these existed when Option::is_some was added, and Option is much more common than Cow.

[clarfonthey]

@petertodd That's fair; that said, though, I think that having methods named is_borrowed or is_owned on a type which implements ToOwned would be extremely unusual, because to_owned would not affect said methods.

@SimonSapin I agree that Option is much more common than Cow, 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.

[clarfonthey]

It appears that this is now merged.

[clarfonthey]

@SimonSapin it would make sense to revert the changes to the title and tags, or discuss here whether the change should be reverted.

[SimonSapin]

Done.

[SimonSapin]

Sorry for the somewhat-pointless churn, I’d gotten here from https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AC-tracking-issue+label%3AT-libs and hadn’t realized there was an implementation PR already.

[clarfonthey]

All good! Thanks for updating things :)

[zbraniecki]

Is anything blocking this from being stabilized?

[fosskers]

Six month check-in: I don't see any issues involving these on the Issue Tracker. Can we move to the next stage?

[antmelnyk]

Quite sad it's not stabilized yet. Are there any issues? 🥲 I find the method would be pretty convenient when cloning of the content under Cow is bad and has to be double-checked for being Owned in critical places.

Example:

if my_expensive_thing.is_borrowed() {
  return Err(MyError::AttemptToCloneExpensiveThing);
} else {
  do_something_heavy(my_expensive_thing.to_mut());
}

[SimonSapin]

At this point I feel this should be fine to stabilize, but until that happens you can match a pattern: #65143 (comment)

[clarfonthey]

Going through some old issues. Is there anything stopping this from going into FCP? I found myself using one of these methods again recently.

[robjtede]

I can't see a strong case for the inherent methods over match cow {} or matches!(cow, Cow::Owned(_)) nor can I think of any compelling uses for passing a Cow::is_owned fn pointer.

Let-else being stabilized surely plays into this decision, too.

[clarfonthey]

I would agree, but there exist other methods like is_some, is_ok, and is_err which are also useful but could be replaced by similar patterns.

EDIT: Note, below may be wrong in most cases:

Another important thing to consider is that the method ensures that you're always borrowing the argument, whereas matches!(cow, Cow::Owned(_)) would consume cow by-value and require adding &cow.

[robjtede]

matches!(cow, Cow::Owned(_)) would consume cow by-value and require adding &cow

That's not the case. See this playground.

You'd have to name the inner pattern for there to be an issue. E.g., matches!(cow, Cow::Owned(_cow)).

[clarfonthey]

Hmm, I guess you're right then. Still, I question whether such usages are always-applicable (e.g. if there's some usage that might break it), and the original point about other methods existing still stands. IMHO, unless those other methods are deprecated (which seems unlikely), this method should be considered for inclusion.