I'm pondering whether the MAD syntax should contain the enum type as well, e.g. EnumElement[MyEnum,mySingle:0] here. In a way it would be more precise, but also more fiddly to specify. There isn't really much ambiguity anyway, because the type is effectively determined by the rest of the MAD signature - though QL performance may be somewhat affected by potential extra rows mid compute.

@MathiasVP do you have an opinion on this?

The dataflow library actually does something like this internally for performance reasons. I'd prefer not including the type as part of the syntax since it increases the chances of us getting a row wrong when we write MaD models 😂

While we're on the top of syntax here, do you think the name EnumElement[...] is best, or perhaps EnumField[...], EnumValue[...] or EnumContent[...]. The documentation appears to call them "Associated Values" (where "Enumeration Values" mean the element name itself).

I'm actually not sure why we shouldn't just support this via the same syntax we use for fields. Is it really important whether it's a field or an enumeration value?

Fields have names, enum associated values do not. In a way they're perhaps closer to a tuple (which we don't have MaD syntax for as yet).

I see what you mean. I was thinking of examples like:

enum Season {
  case spring, summer, autumn, winter
}

and considered whether we could just write .spring for this enum value. But we do indeed need special syntax to handle something like:

enum MyEnum { case mySingle(Int) }

My vote is on EnumElement since that matches what we're doing for ArrayContent.