Here’s Larry’s full message: https://externals.io/message/112417#112469
tl;dr: the enum RFC now doesn’t include value-specific methods anymore. I personally think that’s a very good thing. I explained my thoughts here: https://externals.io/message/112417#112452
Nikita also voiced his concerns about value-specific methods here:
https://externals.io/message/112417#112453
So this won’t be possible:
But this will:
Nice, this is a lot more like what I was expecting.
I think value-specific methods would have been useful in a very small handful of cases, but not definitely not often, and that added complexity probably would have led to them being misused a lot.
This looks a TON cleaner. I actually have found Go enums to be interesting using strongly typed constants:
Now anything type-hinted with Suit will allow either the constant or the string value and it validates. Yes, in this example there is duplication of const name and value but you can also assign functions or errors to them (e.g. HttpError could be an enum of each of the Error “objects” (really: structs), rather than codes or strings. Way more useful.
The addition of iota for int values is also super useful when defining lots of numeric consts.
I’m pretty sure (without checking, as I’m in bed on my phone lol) that this will only actually “type” the Hearts definition as a Suit, and leave the rest as “untyped strings”.
I don’t believe that the types get inferred here automatically like they would with iota.
Just a small thing that I noticed in passing. 😃
EDIT: Yea, verified with the Go Playground.
Like Swift! Beautiful.
My thought exactly – very Swift-like, which is a big plus in my books. Hugely reduces my concerns about permitting methods on enums.
It was actually in part based off of Swift
this is good. I was afraid of those case-defined methods. Now it looks really nice
nice. The original felt kind of convoluted.
Have fun maintaining that
Members
Online