Support constant-folded expressions as enum values

[evantypanski]

from @Mohan-Dhawan on Slack

Spicy does not allow enum fields to be defined using expressions, for example:

type MyPolicy = enum {
  NONE = 0,
  SUCCESS = 1,
  FAILURE = 2,
  ALL = (SUCCESS | FAILURE),
  CLEAR = 4,
};

Is there an easy workaround for this limitation? I am translating from an existing DSL specification in which such expressions are common. Allowing expressions in enum definitions would be a useful enhancement to Spicy

I agree with this. Right now, the enum_label is parsed to only be CUINTEGER (which is just ints and character literals). It'd be nice to have more flexibility.

There are a couple hurdles here, namely that we would need to fold the SUCCESS | FAILURE constant at some point, then validate that to ensure that it's not overlapping with another enum label and whatnot. I think that problem and some related ones would make this tricky, but doable.

[rsmmr]

Not immediately convinced here. The way we use the enum type, is based on all values being distinct. Even if we added support for expressions computing a label's value, I don't think that would then facilicate the use case that's probably desired here (e.g., having a case SUCCESS also trigger for a value of ALL). Changing that would be quite a change in semantics & type system.

[evantypanski]

I don't think that would then facilicate the use case that's probably desired here (e.g., having a case SUCCESS also trigger for a value of ALL).

Hm, I didn't see that as the use case, I think the original point from Mohan was just because that's how the spec expressed the enum. In this case ALL would still be distinct and be 3, which we could technically know at comptime. Having it be equivalent to SUCCESS | FAILURE would just be useful for checking in a bitmask or something (after an int cast), I don't think we would ever support something like case SUCCESS also applying to a different, distinct enum value.

@Mohan-Dhawan is the use case here purely when describing the enum, or also being able to use the "combined" enum values in a case? The former seems like a nice convenience feature if possible, but I agree the latter would be pretty squarely out of scope

As a side note, this case in particular might be even trickier since we'd need to resolve a partial enum to fold SUCCESS | FAILURE

[rsmmr]

having a case SUCCESS also trigger for a value of ALL

(It could actually be the opposite as well I guess: case ALL trigger for SUCCESS.)

Yeah, agree: @Mohan-Dhawan, if you had this, how would you want to use it?