Open union validation #3363
Labels
compiler:core
Issues for @typespec/compiler
design:needed
A design request has been raised that needs a proposal
triaged:core
Milestone
Differentiate open union where values are exhaustive at a point in type
How to differentiate an open union where certain emitters might know the whole set of values and want a more precise type
We estalished that when dealing with union of values that might return different values in the future to an existing API version we should always use an open union
This is an accurate representation of the API.
If a service can guarantee that the values will never change then they can use a closed union or an enum
Problem
Some emitters however would like to represent the more accurate type as they might know all the values and are the ones controlling it(Service) or just want a more precise type that won't affect the runtime(TypeScript client)
And we currently wouldn't be able to differentiate between an union that is open because it might change in the future and an union that currently allows extra values.
Ideas
Opt-in decorator
If a service is using this pattern to represent union that might change in the future it is probably the 99% case that those open union represent the set of current values and doesn't actually allow any values at the latest version. So having a decorator to opt-in to a more precise type would be very tedious as you'd most likely have to apply to to every union.
However if a service doesn't actually care about this - control both end(client and service) or maybe even went and did the work to guarantee that values defined at a version never change(showhow) then the decorator above does seem like a good idea as if they actually use
union WithKnownValues {"a", "b", string }
it most likely mean they accept the extra values.Opt-in service and opt-out decorator
An alternative would be to opt-in a service to this behavior using a decorator on the service namespace
The emitter could be the one deciding to opt-in to this behavior with a flag as well
Usage scenarios
The text was updated successfully, but these errors were encountered: