[constants] Brainstorm for how we should deal with a required, extensible enum of 1, with no client default

Long title, but repeating here: what do you guys think we should do when we encounter when we have an extensible enum of 1 that is a required parameter for a function and it does not have an x-ms-client-default specified in the swagger?

My 2 cents after talking with @lmazuel (thanks for your help!): m4 should set the x-ms-client-default to the single enum value.

Potential drawbacks: the main drawback to this is that if an enum gets added (which it can get added, because it’s an extensible enum), it could be breaking. However, if they add an x-ms-client-default with the original default value to the swagger, the change would not be breaking.

Conclusion (on my and @lmazuel 's side): since it’s easy to make it not breaking, and since as a customer it’s cumbersome to have to specify a parameter that really only has one possible value, m4 should make the one possible value the parameter’s x-ms-client-default

[daviwil]

Thanks for looking into this! Let’s discuss this issue at the AutoRest meeting today to see if we can come up with a reasonable solution.

[iscai-msft]

@daviwil sorry for the late reply, I stopped counting after ~25 examples, and I just made my way to around apimanagement, so I think there are a lot of cases that already have this.

I don’t think in this case it’s enough to catch more of these from entering the specs repo since there are so many already in existence, and I think it’s too much work to add x-ms-defaults for the existing cases.

Here’s some examples:

1. https://github.com/Azure/azure-rest-api-specs/blob/master/specification/advisor/resource-manager/Microsoft.Advisor/stable/2020-01-01/advisor.json#L155
2. https://github.com/Azure/azure-rest-api-specs/blob/master/specification/alertsmanagement/resource-manager/Microsoft.AlertsManagement/preview/2019-05-05-preview/AlertsManagement.json#L1304