Re: [RFC] Enumerations, Round 2

On 04/01/2021 11:15, Markus Fischer wrote:

On 03.01.21 12:01, Mike Schinkel wrote:

So in my perfect world this: enum BookingStatus {

      case PENDING;
      case CONFIRMED;
      case CANCELLED;

} Would be equivalent to: enum BookingStatus {

      case PENDING = "PENDING";
      case CONFIRMED = "CONFIRMED";
      case CANCELLED = "CANCELLED";

}

I'm with Mikes' suggesting here, see also my previous messages [1] [2]. I don't know how to back this up with numbers, but the way I see it the majority of use cases will have a benefit of being able to directly use the literal values derived from the lexical ones and the ability to have custom values is feature next to it.

I would personally be OK with this if it was allowed but opt-in, e.g. adding the ": string" would default the values in that way, or even something magic like ": auto". I'm still not a fan of having values *always* defined, because I want to be able to pick case labels without worrying about whether they make sense as values. For instance, there's a similar maintenance issue to named parameters: having a default value means if I write "case PENDING;" in v1.0, I can't change that to "case PENDING='P';" or "case PENDING=1;" in v1.1, in case somebody is relying on the value being 'PENDING', which was never intended. Regards, -- Rowan Tommins [IMSoP]