Generate enums even with 1 value

[stankovski]

Currently x-ms-enum tagged enums are generated as strings in C#

[amarzavery]

@stankovski @emgerner-msft, @brjohnstmsft , @NiklasGustafsson, @markcowl

When should this happen?

• If the single value enum is an optional model property or an optional parameter and if x-ms-enum extension is provided then it should be honoured.
  • modelAsString: true --> (No Validation happens) A Class with static properties in C#, Java. Node.js will expect the user to provide the underlying primary type on which the enum constraint was specified.
  • modelAsString: false --> An Enum in languages that support Enum. Validation in node.js against the allowed values.
• If the single value enum is a required model property or a required parameter then it should always be treated as a constant. The x-ms-enum extension should be ignored.
  • Some clarifying questions
    • Would it make sense to generate a single value Enum if it is required (Server expects that specific value anyway)?
    • In the future when you add more values to the Enum, then it is abreaking change any way. So does the mechanism of breaking change ["Constant --> Enum with multiple value" OR "Single value Enum --> Multiple Value Enum" ] matter so much ?

[amarzavery]

In addition, allowed values are rendered in the documentation comments for the property or parameter to provide some help to the user.

[amarzavery]

#828

[amarzavery]

closing this as the PR is merged.

[brjohnstmsft]

@amarzavery Why can't this "enum-as-constant" behavior be opt-in? If I put modelAsString: false in my spec, AutoRest should always respect it when the target language supports enums. Instead, right now my model type that uses my single-valued enum now uses string instead of the enum type. In the following code, searchMode should be of an enum type:

        /// <summary>
        /// Initializes a new instance of the Suggester class.
        /// </summary>
        public Suggester(string name, string searchMode, IList<string> sourceFields)
        {
            Name = name;
            SearchMode = searchMode;
            SourceFields = sourceFields;
        }

        /// <summary>
        /// Gets or sets the name of the suggester.
        /// </summary>
        [JsonProperty(PropertyName = "name")]
        public string Name { get; set; }

        /// <summary>
        /// Gets or sets a value indicating the capabilities of the suggester.
        /// </summary>
        [JsonProperty(PropertyName = "searchMode")]
        public string SearchMode { get; set; }

In the future when you add more values to the Enum, then it is abreaking change any way. So does the mechanism of breaking change ["Constant --> Enum with multiple value" OR "Single value Enum --> Multiple Value Enum" ] matter so much ?

Yes, it does matter, because you're creating more work for customers to upgrade to the newer library.

I freely admit that it's lame having a single-valued enum, and it was premature generalization on our part when we designed the API. That said, we have shipped that API and a .NET client that models SuggestSearchMode as an enum, and it really sucks that this is now broken.

Please be careful when making such changes to AutoRest. They really need to be opt-in.

[brjohnstmsft]

The problem with the enum type being modeled as a string was actually a bug that was fixed after 0.15.0, but my original point about being able to opt out of the "enum-as-constant" behavior remains.