> On Jan 4, 2021, at 9:05 AM, Rowan Tommins <rowan.collins@gmail.com> 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'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.
You make a good point about being able to define without defaults, and for being opt-in instead.
A use-case I am thinking about is a long list of application-specific error codes where you
don't want to have to come up two values for each error code and/or worry about keeping them
the same.
I don't quit get how you are thinking of with ": string"; can you give an example?
Conversely, (something like) this might be a viable way to opt-in default values:
enum defaults BookingStatus {
case PENDING;
case CONFIRMED;
case CANCELLED;
}
-Mike