Custom "enum" types with a custom type provider

[davenewza]

In our language context we have dynamic enum-like types. For example, a query might be:

person.status == Status.Married

The enum type Status acts like how we typically understand enum types - it is defined with a set of options. For example, Status.Married or Status.Single would be the defined values.

I'm unsure exactly how to define this with the custom type provider. I've achieved a working solution by defining the enum type as a constant object type and its values as opaque types.

Could this be considered a reasonable approach?

We define all our types dynamically at runtime (and not using Go structs or proto definitions). The below Gist very simply illustrates how I have achieved this:

https://gist.github.com/davenewza/81ebf3f30b0fde94419d9ba090327a5c

What isn't so great about this approach is:

• the issue returned on an invalid expression person.status == Status.wrong is undefined field 'wrong' but enums don't really have fields.
• the issue returned on an invalid expression person.status == Status is found no matching overload for '_==_' applied to '(Status, StatusEnumDefinition)' whereas I might prefer something like value expected for Status
• types.NewNullableType() doesn't seem to let define nullable fields on opaque types

[davenewza]

@TristonianJones - would you be able to help me with this?

[TristonianJones]

Hi @davenewza,

Here are a few tips in no specific order:

• The cel.Constant call should provide a value associated with the variable and type information.
• The contract for operator.Equals is T == T, so you don't really need to create a custom overload
• (reflected in your Gist) Prefer using cel.OpaqueType for a type that has no accessible fields, and cel.ObjectType for a type with accessible fields.
• Avoid using types.NewNullableType() since null should really only be used for JSON values and in some limited circumstances for well-known protobuf types.

Since Status is an ObjectType, the error messages will be based upon a typed field-access. We can certainly update the error message to indicate the type name in addition to the field name. Is this what you're requesting?

The error message for comparing two unequal types is probably about as clear as we can get since we don't have a sense of intent during type-checking.

-Tristan