Future ideas for Provider API support
shepmaster opened this issue · comments
Jake Goulding commented
provide(deref)
shorthand for strings et. al. (String
=> &str
)
For example:
struct Error {
#[provide(deref)]
name: String,
}
Disable providing for opaque errors
For example, make this test pass:
#[snafu(provide(u8 => 1))]
struct InternalError;
struct OpaqueError(InternalError);
assert!(opaque_error.request_value::<u8>().is_none())
Skip providing the value when chaining
For example, make this test pass (ideally improving the syntax as well):
struct ThisProvidesAnI32;
#[snafu(provide(ref, chain, ThisProvidesAnInteger => chained))]
struct Error {
chained: ThisProvidesAnInteger,
}
assert!(error.request_ref::<ThisProvidesAnInteger>().is_none());
assert!(error.request_value::<i32>().is_some());
Change ErrorCompat::backtrace
to use/prefer the Provider API
constituent commented
Currently data provided by the wrapped source
error will be automatically available on the wrapping error. However I have a use case (something like source
itself, that wrapping error and wrapped error should provide different value), that I'd like to disable this default behavior.
I'm using provide(priority, ...
to ensure that data comes from the wrapping error, but I'd like a more explicit feature, maybe provide(no_chain, ...