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 Demand<'a>) {}
}

impl dyn Error + Send + Sync + 'static { // and all combinations of send/sync
    pub fn request_ref<T: ?Sized + 'static>(&self) -> Option<&T> {
        core::any::request_ref(self)
    }

    pub fn request_value<T: 'static>(&self) -> Option<T> {
        core::any::request_value(self)
    }
}

Steps / History

• RFC: RFC: Generic member access for dyn Error trait objects rfcs#2895
• Implementation: Add provider API to error trait #98072
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[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? I believe the syntax thing.core::any::Provider::provide(demand) has been floated 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.

[robamler]

Not sure if this has been proposed before, but maybe an alternative to "fully qualified method call but with deref/autoref" could be that, in case of an ambiguity, trait method resolution favors traits that were introduced in inner scopes.

Currently, the following code doesn't compile:

fn foo(x: u32, formatter: &mut core::fmt::Formatter) {
    use core::fmt::{Display, Debug};

    { // Imagine this block was generated by a macro that only needs `Display` but not `Debug`.
        use core::fmt::Display; // currently leads to a warning: "the item `Display` is imported redundantly"
        x.fmt(formatter); // currently leads to an error: "multiple `fmt` found"
    }
}

The proposal would be to allow the above code, and to resolve x.fmt(formatter) to core::fmt::Display::fmt(&x, formatter) since Display was used in a strictly narrower scope than Debug.

I don't think this would change any behavior in code that currently compiles since it would only disambiguate cases that are currently ambiguous. And it would allow macro authors to simply introduce a new scope and use any traits that their macros will need (this wouldn't leak any identifies to the outer scope since, already today, those uses are scoped to the inner block).