I came across the same problem recently and there were some suggestions to include this unknown literal for all enums at code generation level. One concern i have with that is it introduce unwanted code complexity for all enum handlings. And developers end up in implementing undefined behavior in consumer code for all enums. Do you see the same concerns ?
I like the version API for enum values solution and also if you really want to use enum for something potential change, then define the unknown as part of the API contract and describe it. So API designers can take that decision than a code generator does.
Another option i consider is representing the new value as a attribute in current version of the API provided that this new value can be optional for current consumers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I came across the same problem recently and there were some suggestions to include this unknown literal for all enums at code generation level. One concern i have with that is it introduce unwanted code complexity for all enum handlings. And developers end up in implementing undefined behavior in consumer code for all enums. Do you see the same concerns ?
I like the version API for enum values solution and also if you really want to use enum for something potential change, then define the unknown as part of the API contract and describe it. So API designers can take that decision than a code generator does.
Another option i consider is representing the new value as a attribute in current version of the API provided that this new value can be optional for current consumers.