Investigate supporting 'extensible' enums.

[azure]

Investigate supporting 'extensible' enums.

[jeskew]

Supporting extensible enums may be as simple as distinguishing in parseEnumType between ChoiceSchema and SealedChoiceSchema objects. @autorest/codemodel will use SealedChoiceSchema if an enum's modelAsString property is set to false (per the Autorest docs, this indicates that the enum is closed) and ChoiceSchema otherwise.

For any ChoiceSchema passed to parseEnumType, the non-literal string type would be added to the union type defined for the enum.

[anthony-c-martin]

Possibly related: Azure/bicep#3817 - use of a CSV list of enums raises a warning.

[anthony-c-martin]

Possibly related: Azure/bicep#4064

[anthony-c-martin]

Note that there's also the question of how we fit this into Bicep. I assume we could represent open enums as e.g. 'foo' | 'bar' | string, but we'd need to make sure language features such as completions work well with this, and that we don't accidentally coerce the type down to string. Feels like it's bound to break in a number of places without some work.

We should also think about whether we want to support the common convention of using a CSV-formatted list to support a multi-choice enum (e.g. 'foo, bar'). I'd personally say "no", but I think it's worthy of a discussion.

[jeskew]

Bicep does coerce the type down to string when loading the type, but I was able to get completions working by removing the explicit downcast:

The change causes one test to fail, but it's one that explicitly checks to make sure that specific coercion happens.

I'm not sure I follow the comment about the CSV-formatted list. Would that be how we should display the type signature for a multi-choice enum (instead of however it shows now, presumably something like Array<'foo'|'bar'>)?