Implement Deref to C for Authorization<C>

[jplatte]

I had to undo automatic formatting a few times, I would recommend you run cargo fmt with a recent toolchain so this doesn't happen to other contributors.

[jplatte]

Ping @seanmonstar

[seanmonstar]

Hm, usually Deref is reserved for "smart pointers". The Authorization type doesn't seem like one.

[davidpdrsn]

I think its fine since Authorization is a tuple struct with a single public field and doesn't have any methods (only two constructors). We do something similar in axum on all the tuple structs we have there.

[jplatte]

I think it's common enough for types that aren't really smart pointers to implement Deref. Like in axum, actix-web's extractor types like web::Json also implement Deref to the inner type. SQLx'es Transaction type deref's to a Connection.

[jplatte]

Hey @seanmonstar, how can I move this forward? Would you like to first see some more general discussion about types implementing Deref that aren't smart pointers on the Rust issue tracker or the Rust API guidelines? (I'd guess there's existing issues about it, but not sure)

[seanmonstar]

That'd be fine to link. So far, I'm still not sure this is a case where using Deref is the right pattern.

[jplatte]

Seems like it's pretty clear that the "only smart pointers" rule is wrong, with there being three examples (two stable) of types contradicting it in std:

• ManuallyDrop
• AssertUnwindSafe
• Lazy (unstable)

(from rust-lang/api-guidelines#249)

[jplatte]

@seanmonstar if you're still not (fully) convinced, how about I update this PR to provide impl Authorization<Bearer> and impl Authorization<Basic> with forwarding fn token / fn username / fn password?

[seanmonstar]

That option seems fine.

[jplatte]

Actually just today I wrote some code where I created my own Credentials. I can't implement stuff on Authorization<MyCreds> so am once again wishing for the Deref impl.

Did you look at the issue I linked?