There is a runtime error. But the problem you identify with this method is by design. It is purposefully not exposing which version of the TLS crates are being used, so we can update them.

How does this solution prevent updating them? Also I found the runtime error later... I find it strange that it's put in an enum first, rather than erroring right away, but I was indeed mistaken.

OK, I see the problem now. You don't want TlsBackend to have to be public. This is fixable. Thanks @seanmonstar !

OK, this compiles with the features turned on and doesn't leak any private types 👍 was that your concern @seanmonstar ? There's no way to have ABI compatibility here (as impl Any triggers monomorphization anyway, which gets rid of any possibility of ABI compatibility if the implementation of that function changes), so this should be as forward-compatible as the previous version in any other way.

Thanks for the catch @neoeinstein ! I thought the compiler would've caught such an error -- which it would have done if I'd enabled the correct feature flags when compiling it. My mistake, so thanks for catching it 👍

@seanmonstar : So it has been explained to me that the issue is that upgrading other libraries will potentially cause build failures, which is true. But if this fix is not made, they will instead cause guaranteed runtime failures. Isn't it preferable to have build failures to guaranteed runtime failures, so that the issue can be more readily fixed in CI, without the need for unit testing, which not all client code will have for this situation?

The current method is by-design, with the drawbacks known, introduced in #562. It was asked to change this in #1403, but I re-iterated that it is meant to function the way it does. It ultimately is a situation where no option makes everyone happy. If the types are revealed publicly, then some will complain when we update the versions. With them private, other people will complain. I know we have a warning, it tries to make this clear, but I also very much recognize that warnings aren't usually sufficient.

I feel the best solution is to find what options are being preconfigured, and expose backend-agnostic methods directly in reqwest. This method would continue to be the "I have no other choice, I'll take my chances" option.