You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea is to support something like self->mail(foo).request(bar, 1s).then([](expected<my_type> res) { ... }). If foo is statically typed, we also could infer the type to allow self->mail(foo).request(bar, 1s).then([](auto res) { ... }).
I do have a POC for this, but I'm not happy with it. There's a lot of guessing and meta programming indirections involved that make it rather hard to see what's going on, since the implementation has to fall back to the "regular" code if the handler does not take an expected. A way around this could be to have a separate name, e.g., then_ex, to reduce the complexity of the implementation. Won't be as nice, but at least the user would explicitly opt-in to the alternative implementation.
The text was updated successfully, but these errors were encountered:
The idea is to support something like
self->mail(foo).request(bar, 1s).then([](expected<my_type> res) { ... })
. Iffoo
is statically typed, we also could infer the type to allowself->mail(foo).request(bar, 1s).then([](auto res) { ... })
.I do have a POC for this, but I'm not happy with it. There's a lot of guessing and meta programming indirections involved that make it rather hard to see what's going on, since the implementation has to fall back to the "regular" code if the handler does not take an
expected
. A way around this could be to have a separate name, e.g.,then_ex
, to reduce the complexity of the implementation. Won't be as nice, but at least the user would explicitly opt-in to the alternative implementation.The text was updated successfully, but these errors were encountered: