Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future ideas for Provider API support #352

Open
shepmaster opened this issue Sep 25, 2022 · 1 comment
Open

Future ideas for Provider API support #352

shepmaster opened this issue Sep 25, 2022 · 1 comment
Labels
enhancement New feature or request feedback requested User feedback desired on a design decision help wanted Extra attention is needed

Comments

@shepmaster
Copy link
Owner

shepmaster commented Sep 25, 2022

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

@shepmaster shepmaster added enhancement New feature or request help wanted Extra attention is needed feedback requested User feedback desired on a design decision labels Sep 25, 2022
@constituent
Copy link

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, ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feedback requested User feedback desired on a design decision help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants