Generate visitor interfaces for conjure enums

[carterkozak]

Most uses of enums involve a switch or if-else block across values
along the lines of "boolean isTerminalState(enum)" or
"String getDescription(enum)". It's easy to add new enum values
without updating all usages, by using a visitor we catch these
bugs at compile time rather than runtime.

[markelliot]

Mentioned on #134, but I think we should strongly consider dropping enums in favor of unions and/or switching enum code-gen to use the union code-gen, as enums are really a subset of the union functionality.

[rubenfiszel]

@markelliot One possible migration path is to keep the conjure frontend the same but compile both enum and union to the same internal representation by adding a literal type.

EnumFoo:
  values:
    - a 
    - b
    - c

would be equivalent to:

UnionFoo:
  union:
    - a: literal
    - b: literal
    - c: literal

(can shorten to lit)

and an instance of UnionFoo.a would generate the actual type in the ir: literal<pkg.UnionFoo.a>

Examples of literal types in other languages:

• Typescript: https://basarat.gitbooks.io/typescript/docs/types/literal-types.html + https://basarat.gitbooks.io/typescript/docs/types/discriminated-unions.html
• Scala https://docs.scala-lang.org/sips/42.type.html

[markelliot]

I think a special “none” type would be cleaner and avoid opening up enums to also be used as constants. It’d also satisfy a common union pain point.

After collapsing the codegen, the union codegen probably needs some much closer inspection for clarity and perf.

[carterkozak]

This proposal will cause issues with header and query parameter enum values, we would have to validate that all enum types are lit, and cannot ever receive non-lit values. fwiw I think the use cases for union and enums are fairly distinct, if anything I'd prefer to remove the specifier key from the union type which encroaches on the enums territory.

[iamdanfox]

👍 Lots of the arguments for why we recommend visitors for unions also apply to enums, so I think adding visitor codegen here makes a bunch of sense. Whether we want to eventually unify them or not, I think this is a step in the right direction.

I think discussions about whether we should drop enums completely warrants a dedicated ticket on palantir/conjure as this would affect all languages.

[carterkozak]

Planning to merge tomorrow unless there are strong reservations.