Closed jbr closed 3 years ago
I think we should maintain the distinction between these two types, since it's not especially difficult to dereference StatusCode
when comparing it. Is there a use case where that makes code substantially more onerous?
It's been a bit since I needed this, but I believe it was either for matching or for equality testing between nested types like Option<&StatusCode> without having to .as_deref(). Not critically important, but more convenient
Oh, if we have an API anywhere here which returns Option<&u16>
we should def change it to be Option<u16>
instead. @jbr did you recall whether this was in an http-rs library?
It wasn't in http-rs. The function was returning Option<&StatusCode> and it was convenient to be able to test equality Some(200) or whatever. The other PartialEq was just for parity. Not important behavior, I just didn't see any downside
StatusCode is a thin wrapper around u16, and implements Clone. Simply dereferencing one side, or borrowing another should already work in all cases right?