Mutually exclusive features are suboptimal

[ijackson]

The runtime module of tls-api is constructed so that if both tokio and async_std are enabled, the whole crate fails to compile. (As the docs say, "Currently the features are mutually exclusive.)

This is not great, because cargo features are supposed to be strictly additive: https://doc.rust-lang.org/cargo/reference/features.html#feature-unification

In praftical terms, if a large program contained two separate places where TLS was used, and those two places both used tls-api, and for some reason those two places end up using different runtimes, the system would fail to compile. Normally this kind of situation woudl be undesirable, but doing it ought to be possible, and the "action at a distance" nature of this issue makes it troubling. Having two async runtimes in the same program image is going to happen sometimes.

A possible workaround would be to use cargo's patch feature, or some other mechanism (eg incompatible version requirements) to force cargo to include two separate copies of tls-api, which could each then only have one of the sets of features. (I haven't tried this, but it seems like something along those lines ought to work.)

I appreciate that changing this with the current structure of tls_api is far from straightforward. So perhaps the current situation is the best compromise. I felt it seemed worth filing the issue.

[stepancheg]

I agree.

I think there are two options:

• explicitly make features non-exclusive by small copy-paste. This my preferred option.
• make two copies of the crate