> On Jan 4, 2021, at 9:05 AM, Rowan Tommins <rowan.coll...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to