Closed NyxCode closed 1 week ago
damn, that was fast! :D
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.
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 think this is what @murl-digital wanted in #335, though it might be unrelated if I misunderstood.
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.
one potential issue is handling trait bounds, but i think i can just use a concrete type or something.
Since your definition of struct Item
doesn't make use of the fact that D: Document
, I'd consider if you can just remove that bound. Normally, you only need such a bound on a struct definition if you're using an associated type on Document
.
Even std::hashmap::HashMap<K, V>
doesn't constrain K
or V
, but only the impl<K: Hash, V> HashMap<K, V> { ... }
block does.
Hm, maybe this should be a patch release instead..
Hm, maybe this should be a patch release instead..
This would fit very well in a 9.1.0
, maybe we could even squeeze #316 in with it
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