Andrew Banchich

It would be really nice if Smithy codegen could use `T: Serialize` for input types and `T: Deserialize` for output types instead of concrete values so that users could choose.

To clarify, this is more about the `Document` type using a `HashMap` instead of a `serde_json::Map`. Even if `Document` did impl `Serialize` / `Deserialize`, many users would still need to...

My concern isn't about implementing `Serialize` or `Deserialize`, and it isn't the API for doing so. I'm saying that 99.9% of the Rust ecosystem uses `serde_json::Value` for representing JSON, not...

`aws-sdk-unstable` sounds great to me! Thank you. Any thoughts on handling this with a generic and allowing the user to specify the concrete type? I'd think that would be the...

> Every data type that uses Document would need to accept generic parameters Why? I'm suggesting to do what `serde_json` does here: https://docs.rs/serde_json/latest/serde_json/fn.from_reader.html This would give users to choice to...

That would be nice to have a default generic parameter to allow users to choose the kind of map, but when I said `T: Deserialize` I meant that in place...

To phrase it slightly differently, the point of serde_json is to provide polymorphism over anything which can be serialized into or deserialized from JSON. The Value enum is only one...

This would be fixed with #2858 , which is what I was asking for and more 😄

I had spoken with @hlbarber about this and it sounded like we'd be able to impl FromRequest for our custom types as well. Maybe I misunderstood.

I think exposing this trait would be very beneficial. Smithy cannot serve as a source of truth for all validation rules for inputs, so currently our validation is split between...