Design how we want to represent HashMap input parameters

[antkmsft]

HashMap is not a primitive type. We'd probably want it as RequestContent<T>, but then there's orphans problem. Do we want our own type for them? Leave as-is?

See https://github.com/Azure/typespec-rust/pull/394#discussion_r2150452519 for better context.

cc @heaths

[heaths]

We have the same problem with Vec<T>, but I'm more reluctant to wrap that type because it's practically primitive. For HashMap<Stream, T> I'm thinking a Record<T> much like TypeSpec itself that basically acts like a HashMap<String, T> in all respects. Don't think I want to implement Deref<Target = HashMap<String, T>>, though, because the inner HashMap is an implementation detail. Probably even makes more sense to use a BTreeMap<String, T> like serde_json does since it maintains order.

Or, maybe since this is for unbranded, we just leave as-is until a need arises. Based on REST API guidelines we should never have top-level JSON arrays nor even unmodeled JSON objects, though one could argue that any modeled JSON response is just a map. Not sure we want to support it that way, though. @jhendrixMSFT @LarryOsterman what are your thoughts?