[BUG] - features are not additive about suppaftp

[veeso]

Okay then, I'll manage to fix all these things in the next version then. Thanks for reporting this info.

[veeso]

Yes, I know, but there's no way to do that otherwise, so I don't care.

That's just a trip I mean. Why one should ever need both clients?
I know the cargo reference says that, but it's also true that the language doesn't allow me to do otherwise. I mean, I could rename the stream to asyncstream, but idk.

[OvermindDL1]

Generally they are alternate types (or tag types) for the different types of interfaces yeah. Most commonly the community and rust authors would tend to design something like this like FtpStream<IO> or so, where the different implementations of IO (a sync, a tokio, and an async-std generally, if anyone bothers with async-std nowadays) expose the relevantly useful API's for their own use. Then usually some pub type SyncFTPStream = FtpStream<SyncFTPIO> and TokioFTPStream and AsyncStdFTPStream as well, though not always.

That's just a trip I mean. Why one should ever need both clients?

Oh I know, the program here is split among a lot of libraries that are combined together into a single tower server. One is using the sync API because other stuff they are doing is forced sync on them so why not, and the other is using the async api, but it apparently is causing yet other issues because it's using the mostly-dead async-std instead of tokio for some reason? Trying to convince the async one to switch to the sync since can't seem to get suppaftp to use tokio and just put it behind a spawn_blocking or so like the other person but finding free time to do that is always fun.

---

But anyway, features must always be additive (sync feature, tokio feature, async-std features sound best for here? perhaps with default having sync but that can still be opted out of), everything about cargo assumes that and it will break things if it's not except for the most trivial of programs.