consider exposing error kinds

[hinaria]

(snipped)

[seanmonstar]

hey @hinaria!

I sympathize with wanting to be able to strongly match on the different error variants that can occur. However, there are some reasons that the enum is not exposed publicly.

have my program fail to compile if a new unhandled variant or type is introduced.

That's exactly why the enum isn't exposed, because adding new variants is considered a breaking change, and so if reqwest 1.4 (for example) gained a new feature which meant a new kind of error is possible, that means 1.5, which cargo would automatically update people to, would suddenly break compilation, and so it would then need to be reqwest 2.0.

There is a just-accepted RFC to allow exposing an enum and preventing users from exhaustively matching on it, so that adding new variants is no longer a breaking change. I could see adding a kind method and exposing an enum once that feature is stable. That would mean that you couldn't exhaustively match on the enum, and would require you have to a _ => handle_new_unknown_error() arm.

Many libraries have done this today by naming a #[doc(hidden)] __Nonexhaustive variant, with the hopes of a "I told you so" if anyone actually does match on it...

[seanmonstar]

I'm going to close this for now, so I don't keep thinking there is something for me to merge. But, I don't mean this to mean that the discussion is closed. Feel free to discuss here or in a new issue.