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.

[jakobhellermann]

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

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.

Is this something that just hasn't been implemented yet or was there an active decision to not expose &mut references for now?
I'm thinking we could just add

pub fn request_ref<'a, T>(provider: &'a (impl Provider + ?Sized)) -> Option<&'a T>
where
    T: 'static + ?Sized,
{
    request_by_type_tag::<'a, tags::Ref<tags::MaybeSizedValue<T>>>(provider)
}

+pub fn request_ref_mut<'a, T>(provider: &'a (impl Provider + ?Sized)) -> Option<&'a mut T>
+where
+    T: 'static + ?Sized,
+{
+    request_by_type_tag::<'a, tags::RefMut<tags::MaybeSizedValue<T>>>(provider)
+}

mod tags {
     pub struct Ref<I>(PhantomData<I>);
 
     impl<'a, I: MaybeSizedType<'a>> Type<'a> for Ref<I> {
         type Reified = &'a I::Reified;
     }
+    
+    pub struct RefMut<I>(PhantomData<I>);
+
+    impl<'a, I: MaybeSizedType<'a>> Type<'a> for RefMut<I> {
+        type Reified = &'a mut I::Reified;
+    }
}

but maybe I'm missing something.

[waynr]

@bryanburgers just to follow up, I don't think it's likely in the scope of provide_any or error_generic_member_access that it will be possible to construct Request instances as I mentioned in my previous comments or to use them except in relation to the core::error::Error trait. For reference:

• May 2023 libs team meeting (summary of requested changes](Tracking Issue for Provider API #96024 (comment))
• July 9 2023 confirmation that the libs team meeting only wants this functionality to be available for Error types

Although my opinion doesn't mean much since I am still new to contributing here, I think it's better to keep the API impact of features like this small initially.

As for your original question:

how can non-Error userspace code create a Demand/Request?

One option you could consider is this dyno crate which offers a very similar API. Would that work for you? I'm sure it would be easier to be enthusiastic about a standard library Provider type than an experimental third-party crate 🙃

[waynr]

Not sure what the proper etiquette is for proposing this, but after seeing agreement from @Amanieu in zulip I would like to propose closing this tracking issue in favor of merging what's left of the Provider API into the error_generic_member_access RFC which I have volunteered to update (I'll be opening a PR against that PR shortly after submitting this comment).

The major motivation behind merging these two issues is that the libs meeting has decided to leave out the Provider trait. Without that, all provide_any provides is the Request type which for the foreseeable future will only be used in the Error trait updates proposed in the error_generic_member_access RFC; which anyway already mentions a Request type more or less identical to what has been discussed here.

Merging the two issues would involve the following steps:

• first, make sure there are no major disagreements here in this tracking issue (the purpose of my current message)
• move all outstanding feedback items and next steps from this tracking issue into the error_generic_member_access tracking issue
• submit PR to the rfcs repo to remove https://github.com/rust-lang/rfcs/blob/master/text/3192-dyno.md
• update core/any: remove Provider trait, rename Demand to Request #113464 to replace provide_any feature flag with error_generic_member_access
• close this issue tracking issue
• incorporate the Request (aka Demand) specific elements of RFC 3192 into the WIP RFC 2895

Anyone have any objections to this? I kind of feel awkward jumping in and suggesting it as a newcomer, but again I've had some supportive responses in zulip. I'm happy to take on all this work for the near future as I am currently unemployed anyway.

[Amanieu]

Anyone have any objections to this? I kind of feel awkward jumping in and suggesting it as a newcomer, but again I've had some supportive responses in zulip. I'm happy to take on all this work for the near future as I am currently unemployed anyway.

No objections, this sounds like a good plan. Let me know if you need help with anything.

[waynr]

@Amanieu okay cool, sounds like we've given folks long enough to object. I can't do much keyboard work at the moment because i recently smashed one of my fingers (by mistake of course 🙃) and it needs a few more days to a week to heal before I'm back to my full typing speed. But for now I'll try to assign both tracking issues to myself and start making some of the changes that don't require as much keyboard work.

[waynr]

@rustbot claim

[waynr]

@yaahc I think we've captured everything but

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

in the TODOs for the error_generic_member_access tracking issue so we should be able to close this tracking issue, right?

[jmjoy]

How about add an optional key? Just like:

pub fn provide_value<T>(&mut self, key: Option<&str>, value: T) -> &mut Demand<'a>;

then we can provide multi value with the same type, such as:

struct Sth {
    foo: String,
    bar: String,
}

impl Provider for Sth {
    fn provide<'a>(&'a self, demand: &mut Demand<'a>) {
        demand
            .provide_value::<String>(Some("foo"), self.foo)
            .provide_value::<String>(Some("bar"), self.bar);
    }
}

[waynr]

FEI, the Provider API has been rejected by the libs meeting folks. For more background, please see my earlier comment in this issue: #96024 (comment)

The TL;DR is that the Provider trait has been rejected, leaving just the Request type (aka the type formerly known as Demand) and the new provide method on the Error trait. The Request type and its associated internal-only machinery has been moved from the core::any module into core::error. This is the state of affairs in latest nightly after #113464 was merged earlier this week.

The only thing that's left to do as far as this tracking issue is concerned is to close it (as far as I understand).

[TennyZhuang]

Is there any third-party crate to maintain the Provider trait in the future? Although it may not be suitable to be merged in the std::any, it's still a useful pattern in some scenarios.

[waynr]

@TennyZhuang the closest thing I know of was mentioned in the notes for this feature's RFC, which can be found here: provide-any

I don't know how similar this is to what was unstable here in the standard library and there are no published crates.

[conradludgate]

There is also the supplier crate that I made in response to this feature being removed. I also consider it unstable but it's a direct lift and shift from the latest provider impl that std had in nightly

https://docs.rs/supplier/0.0.2/supplier/

I had plans to change the API but all my attempts so far have failed to be beneficial