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
Currently, Accumulator::handle accepts a darling::Result<T>. This doesn't play nice when using it with non-darling errors (for example, to handle syn error one has to write:
let parsed = accumulator.handle(syn::parse2(tokens).map_err(Into::into));
If Accumulator::handle wound accept Result<T, E> where E: Into<darling::Error>, it would allow to handle other errors without explicit conversion, the same way the ? operator works
The text was updated successfully, but these errors were encountered:
I don't think so. I think handle_inwould have such problems with inference, since typically the closure would want to use ?, leading to double-into. I suspect we just didn't consider the two cases separately.
If someone makes an MR branch, I can do experimental builds of derive-builder (and derive-builder-fork-arti) to see what the impact seems to be in practice.
Currently,
Accumulator::handle
accepts adarling::Result<T>
. This doesn't play nice when using it with non-darling errors (for example, to handlesyn
error one has to write:If
Accumulator::handle
wound acceptResult<T, E> where E: Into<darling::Error>
, it would allow to handle other errors without explicit conversion, the same way the?
operator worksThe text was updated successfully, but these errors were encountered: