Tracking Issue for `error_generic_member_access`

[yaahc]

Feature gate: #![feature(error_generic_member_access)]

This is a tracking issue for the generic member access API on the error trait, which generalizes the pattern of fn source(&self) -> Option<&dyn Error> and fn backtrace(&self) -> Option<&Backtrace> into fn request_ref::<T>(&self) -> Option<&T>

Public API

// std::error

pub trait Error: Debug + Display {
    // existing API unchanged

    fn provide<'a>(&'a self, req: &mut Request<'a>) {}
}

pub struct Request<'a> { .. }

impl<'a> Request<'a> {
    pub fn provide_value<T>(&mut self, value: T) -> &mut Request<'a>
    where
        T: 'static;

    pub fn provide_value_with<T>(
        &mut self,
        fulfil: impl FnOnce() -> T,
    ) -> &mut Request<'a>
    where
        T: 'static;

    pub fn provide_ref<T>(&mut self, value: &'a T) -> &mut Request<'a>
    where
        T: 'static + ?Sized;

    pub fn provide_ref_with<T>(
        &mut self,
        fulfil: impl FnOnce() -> &'a T,
    ) -> &mut Request<'a>
    where
        T: 'static + ?Sized;

    pub fn would_be_satisfied_by_value_of<T>(&self) -> bool
    where
        T: 'static;

    pub fn would_be_satisfied_by_ref_of<T>(&self) -> bool
    where
        T: 'static + ?Sized;
}

pub fn request_ref<'a, T: ?Sized + 'static>(err: &'a (impl Error + ?Sized)) -> Option<&'a T>;

pub fn request_value<T: 'static>(err: &(impl Error + ?Sized)) -> Option<T>;

Steps / History

Now tracked by @waynr in #99301 (comment)

• recent zulip discussion: #t-libs > Pushing error_generic_member_access forward

Unresolved Questions

• None yet.

[dtolnay]

Hello from dtolnay/thiserror#185. I noticed it can be problematic for macros that Provider and Error both have a method named provide. I know this has been the case for other traits (Display and Debug both have a fmt method, for example) but one thing that makes the situation worse for provide is that we're commonly forced to rely on deref in order to call it, so fully-qualified method call syntax is not suitable to resolve the ambiguity:

• In the case of Display, macros can write core::fmt::Display::fmt(&$thing, formatter) and that will always work, because even if $thing is something like Box<dyn Display>, there is an impl<T> Display for Box<T> where T: Display + ?Sized which makes it work.

• However in the case of Error, writing core::error::Error::provide(&$thing, demand) is less good than $thing.provide(demand) because there is no impl<E> Error for Box<E> where E: Error + ?Sized. If $thing is Box<dyn Error + Send + Sync + 'static>, or anyhow::Error, these things rely on the deref done implicitly by .provide(demand) in order to deref to dyn Error + Send + Sync + 'static, which calling fully qualified core::error::Error::provide will not do.

• The situation gets worse as other traits in the ecosystem follow the lead of Error and possibly add their own provide method. Maybe it's not so common that Provider and Error would be both in scope at the same time, but are we confident that Error and arbitrary other ecosystem trait won't be?

Two proposals:

1. There should be impl Provider for Box<dyn Error + …> in the standard library. This makes core::any::Provider::provide(&$thing, demand) accommodate more cases, but still not as good as having a deref.

2. Is there someone who might be interested in pursuing a "fully qualified method call but with deref/autoref" RFC? The syntax thing.core::any::Provider::provide(demand) has been suggested for this in the past, and would eliminate the difficulty for macros that want a deref or autoref but also need to be robust to multiple traits having the same method name.

[JonasJebing]

I agree, that

a "fully qualified method call but with deref/autoref" RFC

would be great.
An immediate remedy would also be to rename Error::provide.
The error_generic_member_access RFC and the dyno/provide_any RFC were already using Error::provide_context instead of Error::provide in their examples.
I'd gladly create a PR to change the name if there are no objections.