-
Notifications
You must be signed in to change notification settings - Fork 116
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
Allow for flattening of generic parameters #336
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
damn, that was fast! :D |
I literally logged into GitHub as the PR was being created lmao |
I think this is what @murl-digital wanted in #335, though it might be unrelated if I misunderstood. |
Looking thorugh the issue, I think this is what they need as well |
i clarified what i wanted in the issue just in case, but i think this would fit my usecase (i'll have to check, though) one potential issue is handling trait bounds, but i think i can just use a concrete type or something. |
Since your definition of |
Hm, maybe this should be a patch release instead.. |
This would fit very well in a |
Hey @NyxCode, since this was release on crates.io, I'll make a corresponding GitHub release |
Goal
Generic parameters currently can't be flattened:
Serde happily accepts this, and we should too.
The three test cases work, and they are compatible with what serde does with them. There may be edge-cases I currently can't think of, though.
However, this change definitely wont break any existing code.
Changes
Tiny change: we just implement
fn inline_flattened()
for the dummy generic types we generate, instead of throwing an error.Checklist