Why is the error type opaque?

[Victor-N-Suadicani]

Why is it that reqwest::Error is opaque and not, say, an enum? It seems like it would already fit as an enum, seeing as it has all these is_* methods.

My specific case is that I would like to differentiate between a serde error and a network error. I can obviously check is_decode but I'm guessing that this method doesn't only return true when serde fails to deserialize a response. It would be easier if reqwest::Error was an enum that, for instance, had a SerdeError variant or something like that. That variant could also hold the specific error returned from serde.

[seanmonstar]

The reason for an opaque error type is for forwards compatibility:

• Exposing directly the wrapped errors in an enum would pin the dependencies to a certain version, preventing upgrading or even replacing them internally.
• Restructuring the kind so as to give better context in a debug message is not possible if the internal enum is exposed.

[Victor-N-Suadicani]

That makes sense - although, is there not a way to get the best of both worlds? 🙂 I mean in an enum, you could still have one variant which could be opaque while other variants could be more structured. So you could expose certain parts but keep other parts private.

But of course, if serde ever does release a 2.0 then that may warrant a reqwest 2.0 as well - but is that a problem? 🤔 I feel like that's just expected. I think in general there's too much "fear" of going beyond 1.0 (or just reaching it; even this hugely popular crate is still unstable). But maybe that's just me. 🤷

How strongly do you feel about this? I'm obviously challenging your opinion here but I don't want to waste time on a PR that is unlikely to be accepted 🙂

[seanmonstar]

While it's true that I'm less concerned with serde's version, I was explaining in general.

It's very unlikely that I will change this.