Support tsp union types

[jhendrixMSFT]

TypeSpec defines union type which looks to be analogous to discriminated unions a la TypeScript. We might be able to emulate this via polymorphism (needs prototyping/experimentation).

[jhendrixMSFT]

Three ideas.

• polymorphism
• closures
• unexported type

[jhendrixMSFT]

Given that union types are very minor and banned in Azure services, the current POR is to expose them as raw JSON, i.e. []byte.

[jhendrixMSFT]

After discussion, we've decided to not add any support for union types.

CC @tadelesh

[tadelesh]

do you mean leave it as a binary just like java and .net?

[jhendrixMSFT]

We won't add any support for it (it's a fair amount of work to make this happen as the tcgc representation needs modification to improve the codegen). So, if a tsp contains a union, the emitter will fail with an "unsupported kind union" error.

The reason we don't want to add binary support is because the usability is terrible. Sending isn't as bad, but when receiving, how is a customer supposed to understand what types are possible and how do they unmarshal it in a robust way?

Further, per conversations with @JeffreyRichter unions won't be allowed in tsp Azure services for this exact reason. In practice, this means that not supporting unions has little practical risk.

[tadelesh]

We won't add any support for it (it's a fair amount of work to make this happen as the tcgc representation needs modification to improve the codegen). So, if a tsp contains a union, the emitter will fail with an "unsupported kind union" error.

The reason we don't want to add binary support is because the usability is terrible. Sending isn't as bad, but when receiving, how is a customer supposed to understand what types are possible and how do they unmarshal it in a robust way?

Further, per conversations with @JeffreyRichter unions won't be allowed in tsp Azure services for this exact reason. In practice, this means that not supporting unions has little practical risk.

Thanks for explanation. I also dislike union and believe if do need union then service should be responsible for adding customization code for serialization and deserialization. Since Go only need to support MPG with TypeSpec for now, I'm good with the solution.