Tracking Issue for Provider API

[yaahc]

Feature gate: #![feature(provide_any)]

This is a tracking issue for RFC 3192

This RFC proposes extending the any module of the core library with a generic API for objects to provide type-based access to data. (In contrast to the existing APIs which provides type-driven downcasting, the proposed extension integrates downcasting into data access to provide a safer and more ergonomic API).

The initial motivating use case for this API is to provide the necessary functionality to add generic member access to the Error trait to generalize extracting context like Backtrace and to make it possible to move the Error trait into core while leaving Backtrace in std.

Public API

// core::any
pub trait Provider {
    fn provide<'a>(&'a self, demand: &mut Demand<'a>);
}

pub fn request_value<'a, T>(provider: &'a (impl Provider + ?Sized)) -> Option<T>
where
    T: 'static;

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

#[repr(transparent)]
pub struct Demand<'a>(_);

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

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

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

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

    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: ?Sized + 'static,
}

impl<'a> fmt::Debug for Demand<'a> {}

// core::error
impl<E> Provider for E
where
    E: Error + ?Sized;

Steps / History

• Implementation: Add the Provider api to core::any #91970
• Delete the Provider trait and merge its functionality into Error.
• Pick either demand or request and use that name consistently.
• LLVM is unable to optimize multiple .provide_* calls into a switch table because each call fetches the type id from Erased::type_id separately each time and the compiler doesn't know that these calls all return the same value. This should be fixed. See Add provide_any module to core rfcs#3192 (comment) for one possible solution (although alternative solutions may be possible).
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should the APIs be named demand_* or request_*?

[yaahc]

#98912 updates the request_* functions to have an APIT (arg position impl trait) parameter instead of a standard generic parameter to remove unnecessary inferred parameters while turbofishing.

Callers change:

let obj: Box<dyn Provider> = Box::new(SomeConcreteType { some_string: "hello".to_owned() });

// From
assert_eq!(&**request_ref::<String, _>(&*obj).unwrap(), "hello");

// To
assert_eq!(&**request_ref::<String>(&*obj).unwrap(), "hello");

[dtolnay]

One minor thing that weirds me out about this API is this impl:

rust/library/core/src/error.rs

Lines 197 to 199 in 02654a0

	impl<E> Provider for E
	where
	E: Error + ?Sized,

Since this is a blanket impl (Self type is a generic parameter), it is the one blanket impl that Provider is ever going to be able to have, at least absent some far-future negative impls feature in the language. Any other blanket impl would be considered overlapping and violate coherence.

But it's a blanket impl of core::any::Provider, which is envisioned as being as general-purpose as the Any trait, for types which implement core::error::Error, which is a much narrower use case. In some sense this relationship is saying that "Errors are the one true canonical/privileged implementers of the Provider trait; any other application of Provider is second-class".

I am wondering which one of the following would be feasible:

1. Yes, errors are the one privileged application of Provider, and while Provider may be useful for some other things sometimes, all of those are second-class.

   a. Maybe move Provider to core::error to double down on this view?

2. Remove the blanket impl. What are the things that make the blanket impl necessary for usability of this API, and can those be mitigated a different way?

[yaahc]

We could go back to what we had before we move Error into core which was a provide impl just on dyn Error which caused some other paper cuts but I can't remember exactly what those issues were.

[thomcc]

Another issue for the provider API that matters for non-error cases is the lack of support for &mut.

I think the initial proposal did support this, at some cost to complexity. While I don't know that we need to support it out of the gate (I've wanted it multiple times when playing around with the API), it would be good to be sure we know it would look like, so that if we want to add it in the future, that we have not painted ourselves into a corner where we cannot do so.

[yaahc]

@thomcc I believe all we have to do is expose the tag APIs to support those cases. We didn't change the impl, only the exposed API.