impl AsRef<Uuid> for Uuid

[koshell]

Added the following AsRef impl:

impl AsRef<Uuid> for Uuid {
    #[inline]
    fn as_ref(&self) -> &Uuid {
        self
    }
}

Having this means you can write code like this that accepts Braced, Hyphenated, Simple, Urn, or Uuid:

fn find_with_uuid(uuid: impl AsRef<Uuid>) 

For completeness this is technical possible currently using something like this:

fn find_with_uuid(uuid: impl Borrow<Uuid>) 

However (and I am open to being corrected on this) my understanding is this is much less idiomatic then AsRef<T>. My understanding after reading over the std docs and some discussion online is:
Borrow<T> implies a function doesn't care if it gets T, &T, or &mut T.
AsRef<T> implies a function doesn't care what it gets as long as it can be represented as &T.

They both serve similar purposes (and have almost identical implementations). However AsRef<T> implies "I want &T and I don't mind if I need to do a low cost conversion to get it" where Borrow<T> implies "I don't care if you give me T or &T since I'll be borrowing it as &T anyway."

As an example the standard library recommends using AsRef<str> when you want a function to be able to accept any &str, &String, or String.

(Ideally the standard library would implement something like:

impl<T> AsRef<T> for T {
    #[inline]
    fn as_ref(&self) -> &T {
        self
    }
}

However currently this isn't possible due to some other conflicting traits so it needs to be implemented manually for each type.)

[koshell]

New AsRef made this ambiguous.

[koshell]

New AsRef made this ambiguous.

[KodrAus]

Thanks for the PR @koshell. I'm a bit reluctant to add this since it does break inference. I'm not sure how widely relied on that is, but since we do already have a way to abstract over Uuid and its various format types via Borrow I'd rather err on the side of caution on not introduce this. Adding a generic bound on Borrow<T> is perfectly idiomatic, the trait itself is just less widely pushed because of its additional implementation constraints that you can't enforce through the type system.

[koshell]

That's fair. I will say the documentation for AsRef in the std library does say this:

Reflexivity

Ideally, AsRef would be reflexive, i.e. there would be an impl<T: ?Sized> AsRef for T with as_ref simply returning its argument unchanged. Such a blanket implementation is currently not provided due to technical restrictions of Rust’s type system (it would be overlapping with another existing blanket implementation for &T where T: AsRef which allows AsRef to auto-dereference, see “Generic Implementations” above).

A trivial implementation of AsRef for T must be added explicitly for a particular type T where needed or desired. Note, however, that not all types from std contain such an implementation, and those cannot be added by external code due to orphan rules.

This suggests that while it isn't possible to currently enforce it, it should be assumed to be reflexive (and could possibly become an automatic implementation in a future version of rust-std).

The fact that it creates some inference issues in this case is mildly annoying but I think would only be a minor semver change since your just expanding a trait. The same inference problem could theoretically happen with any new AsRef implementation for a type.

Would a feature flag for the implementation be preferable? Since there is no way to implement this outside of this crate that would mean people could enable/disable it as they saw fit. Ideally if nobody reports any issues you could just include the feature flag in the default flags after a time. I'm happy to implement that in the branch if that would be better.

[KodrAus]

I've spent some more time thinking about this, and I've come around to adding impl AsRef<Uuid> for Uuid. The inference breakage is unfortunate, but I realised I avoid the pattern of let b = a.as_ref() in code anyways unless there's a type bound either on the let binding or through a generic bound on the type of a that isn't reliant on inference anyways. AsRef without a concrete bound somewhere is not only brittle, it's also difficult to tell from reading the source what you're actually asking for.

So I think we're potentially breaking a pattern I'd generally recommend against anyways, and there's no logical reason you can't or shouldn't add a reflexive AsRef.

[KodrAus]

The build break here should be fixed if you rebase on main.

[KodrAus]

I'm putting together a new release so will merge this one in and deal with any breakage in a follow-up. Thanks again @koshell!