serde_as with smallvec::SmallVec

[homeassistant-hacs-m]

In v1, I used to be able to do

#[derive(Deserialize)]
#[serde(transparent)]
struct Quix {
    #[serde(with = "serde_with::rust::tuple_list_as_map")]
    foo: SmallVec<[(Bar, Baz); 7]>,
}

using serde_with::rust::tuple_list_as_map
This has seemingly been removed since v2, leaving only the macros.

use serde_with::{serde_as, Map};
#[serde_as]
#[derive(Deserialize)]
#[serde(transparent)]
struct Quix {
    #[serde_as(as = "Map<_, _>")]
    foo: Vec<(Bar, Baz)>,
}

The above works for Vec<T>, but not for SmallVec<[T; N]>

Is there any way to work around that on newer versions and restore functionality of all T: FromIterator and &T: IntoIterator types?

[jonasbb]

Yes that is an unfortunate effect of the change. the Map type is more general in that you can apply transformations to the inner types (e.g., Map<DisplayFromStr, _>). But that comes at the cost of no longer being generic over FromIterator/IntoIterator. However, it should be possible to explicitly support all the types people actually care about, like the existing support for indexmap or hashbrown. That can be extended to support smallvec.
I happily take a PR to implement smallvec support.

The problem is with unspecified generics, mainly during deserialization. For example, the String type supports FromIterator<char> and FromIterator<Box<str>>. A hypothetical Seq<DisplayFromStr> now has no way to decide which FromIterator implementation to pick.

[homeassistant-hacs-m]

I would be interested in making that PR sometime.
However, I am curious to confirm whether you think exposing some such functions/modules that can be used with serde(with= would be inappropriate and not something you'd want for this library.

[jonasbb]

I removed those modules from serde_with since I think the new types are generally more useful and having both options is too confusing.

The code of serde_with is liberaly licensed, so you have the option of just copying the module you need from v1.