Open Velnbur opened 1 month ago
It's quite popular I would say: https://github.com/search?q=BoxTryFuture&type=code
It's quite popular I would say: https://github.com/search?q=BoxTryFuture&type=code
Only 4 seem to be unique (tide, tinychain, txn_lock, tokio-tide, and tokio-tide's code is in comment). All the others seem to be forks of tide and tinychain.
You're right. So you consider this extra for now? I still think that this is quite useful.
Also, the search can be extended by looking for the usage of
BoxFuture<Result*
.
I can see that the usage of BoxTryFuture<Ok, Err>
instead of BoxFuture<Result<Ok, Err>>
could be controversial. Especially in cases when Error
is hidden in a type alias like BoxFuture<Result<Ok>>
, because for someone the last one is more convenient. But refactoring this:
async fn get<'a>(&'a self) -> BoxStream<'a, Result<BoxFuture<'a, Result<T, Error>>, Error>> {
to this:
type ItemStream<'a, T, Err> = BoxTryStream<'a, BoxTryFuture<'a, T, Err>, Err>>;
async fn get<'a>(&'a self) -> ItemStream<'a, T, Error> {
made my day :)
BoxFuture
andTryFuture
are already in lib, but why notBoxTryFuture
? The same goes forBoxTryStream
andTryStream
. I'm declaring both of them quite often, maybe I'm not alone with this problem, so why not add them tofutures
after all?