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

TODO: Update this section once the implementation PR is merged

Steps / History

• Implementation: Add the Provider api to core::any #91970
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

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

[JonasJebing]

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.

Here's the discussion that lead to impl<E: Error + ?Sized> Provider for E: #98072 (comment)
So, the paper cut without the blanket impl is, that it's not possible to call core::any::request_* or <dyn Error>::request_* on a concrete error type like std::io::Error.

Personally, I feel like there are a lot of possible workarounds for that paper cut:

1. The concrete error type could allow public access to its fields or getter functions;
2. The concrete error type could impl Provider for SomeConcreteError
3. A user can always create an adapter/newtype that implements Provider using Error::provide on the conrete error type.

So, I am leaning towards impl Provider for dyn Error instead of the blanket impl.

[JonasJebing]

@jakobhellermann you're missing that Provider::provide just has a shared reference &self.
So, a fn provide_mut<'a>(&'a mut self, _req: &mut Demand<'a>) {} needs to be added to the Provider trait, too.

@yaahc, @thomcc the Provider support for &mut was addressed in the RFC under "Future Possibilities".
The linked repository even includes an API for providing different &mut types to the same field or struct:

    fn provide_mut<'a>(&'a mut self, req: &mut Demand<'a>) {
        req.with(self)
            .provide_mut::<String>(|this| &mut this.string)
            .provide_mut::<str>(|this| &mut *this.string);
    }

[Kixunil]

First of all, I think this idea is really great so big thanks to all people participating on the design and implementation!

One thing that's puzzling me is the limitation of T: 'static. I don't see any reason for it besides possible compatibility with Any. (Could there be simply another method enforcing static?)
What I'd like to do is to provide singular value that may reference data inside the error. To be specific I'm very interested in having a common API for spanned errors that can be displayed nicely while being detached from rendering (codespan-reporting, miette...)

pub struct SpannedLabel<'a> {
    span: Span,
    label: &'a dyn fmt::Display, // maybe this should be an enum supporting `String` and `Box<fmt::Display>`
    file_id: FileId, // didn't figure out the exact type yet
}

#[derive(Copy, Clone /* ... */)]
pub struct Span {
    pub start: usize,
    pub end: usize,
}

One way to resolve this issue is to provide the values separately. This is not entirely unreasonable but I worry it'll lead to people forgetting about providing one of the two values.

Also I found this in the motivation section of the RFC:

this approach is limited by constraints on Any, we cannot return objects by value, return objects which include references (due to the 'static bound on Any),

But this still only works with 'static and is even acknowledged by the RFC:

The proposal only supports handling value types (or other types with only 'static lifetimes) and reference types.

Which sounds contradictory and I don't see it explained anywhere.

[conradludgate]

One thing that's puzzling me is the limitation of T: 'static

I'm not sure on the nitty gritty details of typeid and Any (and I hear there's a lot of cursed stuff to know) but T: 'a and T: 'b would definitely need to be different types (need to be very careful with subtyping etc).

Now, playing devils advocate as a non compiler engineer, I think trying to make sure that T: 'a and T: 'b have different unique typeids would be a lot of work, especially since we have troubles with that for T and U anyway

[Kixunil]

@conradludgate I don't see how it's relevant. AFAIK this implementation bypasses typeid and Any completely.

[conradludgate]

AFAIK this implementation bypasses typeid and Any completely.

It bypasses Any (using a trait called Erased instead), but still uses TypeId

rust/library/core/src/any.rs

Lines 1285 to 1287 in 8e68090

	if self.tag_id() == TypeId::of::<I>() {
	// SAFETY: Just checked whether we're pointing to an I.
	Some(unsafe { &mut *(self as *mut Self).cast::<TaggedOption<'a, I>>() })

[mstone]

(With apologies if this is a bad place to ask:) while we are discussing continuing appearances of this "type_id() is lifetime-insensitive" limitation w.r.t. to type-directed programming + reflection, is there additional history or context, such as a good issue to link to, for those who would like to know more about the overall problem?

(Also, if it helps, what I've got for context so far mostly consists of, going from older to more recent:

• https://rust-lang.github.io/rfcs/1849-non-static-type-id.html
• Tracking issue for non_static_type_id #41875
• https://internals.rust-lang.org/t/pre-rfc-non-footgun-non-static-typeid/17079

as well as for the sub-issue that arises within some of these conversations of not breaking inference while adding generics (with defaults where necessary) to existing signatures:

• https://faultlore.com/blah/defaults-affect-inference/ )