Go inputs/outputs can't be serialized/deserialized into valid smithy

[DanielBauman88]

The StructureGenerator creates input and output types for smithy actions.
Unlike in other languages, the fields in the generated types are capitalized. This is done because they need to be exported and go uses capitalization for this.

A consequence of this is that the types can't be simply serialized with go's default serialization library as the capitalized field names won't necessarily match what smithy defines.

These input/output types are not strictly required to be serializable by default, but it would make working with the go types generated by smithy-go a lot easier. This could be quite easily supported by simply adding struct tags with names matching those defined in smithy to all the capitalized fields generated by the structure generator.

It seems like the smithy-go team explicitly doesn't want these types to be used in serialization/deserialization based on the noSmithyDocumentSerde that is generated. What's the reasoning for this?

Just trying to get a better understanding of the intent to better shape our use of smithy-go.

Asking because for our use-case having the structures generated with struct-tags matching the smithy names would be very convenient and useful but it seems like this is something smithy-go explicitly wants to exclude.

[jasdel]

Thanks for reaching out. There are a couple other issues that are related to this ask, #372, and #326.

One issue that needs to be addressed for struct tags and general Go Standard library json encoding behavior support, is how are members with types such as Time, blobs and streams (io.Reader) handled.

[lucix-aws]

Covered by #458, protocol serde should handle this.