This would be extremely useful for things like serde_json::RawValue and similar!

Although it would need to apply to Deserialize as well.

I can certainly add it for Deserialize, too!

FWIW I'm just a drive-by reader, not maintainer of Serde, although I could very much make use of such feature if it ever lands to avoid hacks for communication between deserializer & custom type in serde-wasm-bindgen.

I don't know about the timeline on std::any::Provider stabilization, but if/when it lands this would indeed be a great solution to the serializer-specific specialization problem.

I think having the default provider method is valuable.

While it is valuable for everyone who needs it, it also adds a just-for-convenience method to an already extremely big trait. Afaict even the SerializerProvider type is not needed in serde itself, right?

I don't know about the timeline on std::any::Provider stabilization, but if/when it lands this would indeed be a great solution to the serializer-specific specialization problem.

🥳

Yeah, I'm aware that std::any::Provider isn't stabilized, and I'm in no hurry.

I think having the default provider method is valuable.

While it is valuable for everyone who needs it, it also adds a just-for-convenience method to an already extremely big trait. Afaict even the SerializerProvider type is not needed in serde itself, right?

I suppose there's a balance here between smaller API surface and more documentation burden.

• Serializer::provider method + SerializerProvider
  • Adds an unnecessary method to the trait
  • Documentation says "Use serializer.provider()"
• SerializerProvider only
  • No unnecessary method on the trait
  • Documentation says "Use SerializerProvider::wrap(&serializer)" and users need to know about SerializerProvider
• Neither
  • No unnecessary method on the trait
  • No extra SerializerProvider and DeserializerProvider structs
  • Documentation has at least one example of creating your own Provider adapter and then using it

serde is a huge part of the Rust ecosystem, so I'm going to defer to you if we fall at different points on that balance.

I'll be glad to take that stuff out and update the documentation.

This would be very useful for deserialization to add an ability to provide spans of deserialized objects to the Deserialize implementation aware of spans. Unfortunately, deserializer is consumed during deserialization so providing safe interface and implementation could be impossible (it could not be possible to ask deserializer of spans after deserialization because it is consumed).

I was able to implement such a concept by extending Deserializer trait with safe interface, but with unsafe implementation, a sketch:

trait PositionProvider {
  type Position;

  fn current_position() -> Self::Position;
}
trait Deserializer<'de> {
  type PositionProvider: PositionProvider;

  fn position_provider(&self) -> Self::PositionProvider;
  ...
}

// impl
impl<'de, 'a> Deserializer<'de> for &'a mut MyDeserializer {
  type PositionProvider = MyPositionProvider;

  fn position_provider(&self) -> Self::PositionProvider {
    MyPositionProvider(self as _)
  }
}

// Cannot use reference here because of borrow checker
// and that fact that deserializer is consumed during deserialization
struct MyPositionProvider(*const MyDeserializer);
impl PositionProvider for MyPositionProvider {
  type Position = usize;

  fn current_position(&self) -> usize {
    let de: &MyDeserializer = unsafe { &*self.0 };
    de.current_position();
  }
}

Then any type can be wrapped into

struct Spanned<T> {
  value: T,
  span: Range<usize>,
}
impl Deserialize<'de> for Spanned<T>
where
  T: Deserialize<'de>,
{
  fn deserialize<D>(deserializer: D) -> Result<Self, D::Error> {
    let provider = deserializer.position_provider();
    let start = provider.current_position();
    let value = T::deserialize(deserializer)?;
    let end = provider.current_position();

    Ok(Self { value, span: (start..end).into() })
  }
}

This trick is only worked for deserializers that implements Deserializer for a reference to the deserializer struct (but it seems most of the deserializers implemented like that)

@Mingun You could just make position_provider return an Rc<Cell<...>> or something. It doesn't have to hold a reference to the Deserializer - instead, Deserializer could own position provider and hand out its Rc-clones to anyone who wants them, making the code safe.

Looks like the Provider feature has been removed from nightly Rust in favour of just extending the Error trait, so this PR is sadly no longer viable.

Actually, the Provider trait was needed only to use std::any::provide_value helper method. It is still possible to implement that method in serde for use with Serializer / Deserializer.