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

Suggest #[serde(bound="")] when encountering failure to infer bounds #1828

Closed
graydon opened this issue Jun 7, 2020 · 2 comments
Closed

Comments

@graydon
Copy link

graydon commented Jun 7, 2020

I filed a compiler bug on this too (rust-lang/rust#73082) but it would have been helpful to see suggested in the serde docs that when encountering a type annotations needed / cannot infer type for type parameter error when attempting to derive(Deserialize), the solution isn't always to add an annotation or to specify a Deserialize bound: in the case I ran into today (where the type parameter it was struggling with already implements DeserializeOwned), the solution is to annotate with #[serde(bound="")], disabling serde's attempt at inferring a bound entirely.

I can't tell whether the right place to discuss this would be in https://serde.rs/container-attrs.html or https://serde.rs/attr-bound.html or some other place, the nearest hint I found on the matter was on stackoverflow (which I've added an extended answer for, in case anyone stumbles on it again: https://stackoverflow.com/a/62239787/1669902)

@swfsql
Copy link

swfsql commented Oct 19, 2021

Related issue: #1296

@dtolnay
Copy link
Member

dtolnay commented Jul 9, 2023

I think it's unlikely that adding information about this to the documentation would be a net benefit. In general, with more documentation of edge-cases, people read even less of the higher-value documentation, because the overall relevance is diluted. I think this specific issue comes up seldom enough that Stack Overflow can be sufficient coverage.

In your case, going by the rust-lang/rust issue, the problem was a consequence of rust-lang/rust#41617, which I am still hopeful will get fixed in rustc eventually.

@dtolnay dtolnay closed this as completed Jul 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants