Re: [RFC] Enumerations, Round 2

Hi, On 04.01.21 15:05, Rowan Tommins wrote:

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 can't say whether just : string is too much, but in general I like it. I can follow the reasoning having no value by default and opt this in. The opt-in you suggested is very low-overhead (albeit a bit subtle, but maybe someone has a smarter idea :) Maybe not evident, I like the enum RFC but think the most value for many use cases will having automatically values. thanks! - Markus