David Tolnay

@kpozin @jaen, I am still interested in landing this feature but I have been bottlenecked on review bandwidth for many months, and this feature has been relatively low value for...

@jaen that's awesome -- could you share your rebased code in a new PR? It doesn't have to be perfect.

Thanks! I copied it over to https://github.com/serde-rs/serde/pull/1644 so we don't lose the work if you decide to delete your fork later.

I would be on board with 2. The issue with 1 and 3 is they make it impossible to later reimplement using an arbitrary precision number library, which would be...

Awesome idea. I think this boils down to expanding `json!(...)` into some anonymous type that implements the Serialize trait. ```rust serde_json::to_value(json!({ "x": [x] })) ``` ```rust serde_json::to_value({ struct _A where...

Your way would not have worked because of the signature of SerializeSeq::serialize_element: ```rust fn serialize_element(&mut self, value: &T) -> Result where T: ?Sized + Serialize; ``` It requires that you...

You should be able to just use the same identifier for all of them and set up the scoping so that the right one gets resolved in the right place....

I would prefer not to do that because it would artificially limit the length of arrays you could use with this syntax. We only have Serialize impls for small tuples.

I would strongly prefer not to limit keys to be just identifiers. Is there a way to structure the expanded code such that dynamically generated generic type bindings and struct...

Seems reasonable. Do you have a suggestion for how this should work? Simplify changing the meaning of `rename_all` would be a breaking change. Side note: representing the datastore value the...