Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make serde_as easier to use for identity transformations #202

Open
jonasbb opened this issue Oct 30, 2020 · 0 comments
Open

Make serde_as easier to use for identity transformations #202

jonasbb opened this issue Oct 30, 2020 · 0 comments
Labels
enhancement New feature or request

Comments

@jonasbb
Copy link
Owner

jonasbb commented Oct 30, 2020

As seen in #201 it might be confusing why this code doesn't work:

// Can't get this working at all
#[serde_as(as = "BTreeMap<String, ADef>")]
pub map: BTreeMap<String, A>,

// Confusingly enough defining identity transform like this doesn't compile either
#[serde_as(as = "BTreeMap<String, String>")]
pub map2: BTreeMap<String, String>,

The reason is that a blanket implementation for DeserializeAs/SerializeAs is not possible as it would overlap with other implementations. It is possible to special case the impl SerializeAs<String> for String case. This has to be done for every type and would bless the standard library types compared to types from crates.

Another possibility might be to move this logic into the serde_as macro. If it detects two identical types it replaces the type in the as part with _/Same. In the map case the BTreeMap<..., ...> compares not equal, but the String subtype does and would be replaced. In the map2 case already the BTreeMap<..., ...> type is equal and it would convert it to as = "_".

This could technically change how the serialization is performed as it then uses Serialize instead of SerializeAs. So this behavior might require an opt-out which disables the type equality check.
Another option might be to limit this to leaf types, i.e., ones without any generic parameters, since I assume it might be more likely there.

A problem with this approach is how to generalize this to different transformations, for example the BTreeMap<K, V> to Vec<(K, V)> transformation. The first one has two generic arguments while the Vec only has one (the tuple). So the fear here is that it simplifies it for the trivial cases but as soon as somebody want to use other transformations the help would fail and that might cause even more confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant