Add a `parse` static or factory ctor to Enum

[kevmoo]

C# has it: https://docs.microsoft.com/en-us/dotnet/api/system.enum.parse?view=netframework-4.7.2

The opposite of #30021 & https://github.com/dart-lang/sdk/issues/21712 – where we want the simple string name of the value.

Related to #21966 as this makes interop VERY hard. Have to do a lot of messy string tricks

[leafpetersen]

Given:

enum Day {
  monday, tuesday, wednesday, thursday, friday, saturday, sunday
}

Is it enough to be able to do Day.parse("monday")? Or do you want to be able to say Enum.parse(Day, "monday")? Note that the latter is strictly more powerful, since I can presumably do

class A<T> {
  var a = Enum.parse(T, "hello"); // Better hope T is an enum type with a "hello" tag
}

and

dynamic mkHello<T>() => Enum.Parse(T, "hello");

[kevmoo]

Honestly, I'd prefer `static Day tryParse(String value, bool ignoreCase)` Obviously, if the enum has 'bob' and 'BOB', passing ('bob', true) throws...

…

On Fri, May 25, 2018 at 5:50 PM Leaf Petersen ***@***.***> wrote: Given: enum Day { monday, tuesday, wednesday, thursday, friday, saturday, sunday } It it enough to be able to do Day.parse("monday")? Or do you want to be able to say Enum.parse(Day, "monday")? Note that the latter is strictly more powerful, since I can presumably do class A<T> { var a = Enum.parse(T, "hello"); // Better hope T is an enum type with a "hello" tag } and dynamic mkHello<T>() => Enum.Parse(T, "hello"); — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#33244 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABCimm9N00Y2YhWEm1S0GAokBkN3jPAks5t2KbigaJpZM4UOtMT> .

[lrhn]

I'm not very happy about conflating source names and strings.
On the other hand, the toString already does so, so we have to retain string representations of the source name anyway.

Adding members to enum classes takes up namespace for values, so adding a parse method would prevent having a parse enum entry. I guess tryParse is obscure enough that it's not going to conflict.

The ignoreCase parameter makes sense now, because names are ASCII only, but if we ever allow source names to be arbitrary Unicode identifiers, I'd be very worried about having to do case-insensitive text comparison here.

All in all, I think we should do a proper work-over on enums rather than add features piecemeally.

[lrhn]

One, non-breaking, option is to change the values field to be a class that still implements List, but which also has a byName function (or even a byName map). Then you write:

Day.values.byName("monday") // if `byName` is a Day Function(String)
// or
Day.values.byName["monday"]  // if `byName` is a Map<String,Day>.

I would only accept the name that occurs in toString, no case insensitivity. Whether to accept other representations should be purely client discretion, not something we try to speculate on.

(I'd prefer to change toString to not include the type prefix, it's annoying to have to split the result to get the name, and I also don't want to add a name getter on enums, since it conflicts with the enum declarations. It's a breaking change, though).

[MatrixDev]

I would also suggest to allow developers to write custom parse methods inside enum itself:

enum Day {
  monday, tuesday, wednesday, thursday, friday, saturday, sunday;

  static Day parseDb(String dbValue) => ...
  static Day parseJson(String jsonValue) => ...
}

[lrhn]

Allowing static members inside an enum declaration should be trivial. They'd have to not be named index or values, the two members that all enums have, or the same as any enum value, but otherwise there is no problem.

We might want to allow instance members too, and have something closer to, say, Java's enum declarations, but that's a much larger change.

[MatrixDev]

Having Java-like enums would really be perfect. But if static functions are more trivial - I'd say to add them first. It will significantly reduce global namespace pollution (aka parseDay -> Day.parse).

[Levi-Lesches]

I like the idea of adding static members to an enum. Then automatically adding something like static MyEnum parse(String)
shouldn't too difficult. Again, just like MyEnum.values, if we choose a name for this function/map that's people aren't using as enum values, it shouldn't be that big a deal.

[marcglasberg]

This is what works best while this is not implemented:

extension EnumExtension<T> on List<T> {

  T from(String value) => firstWhere(
        (e) => e.toString().split('.').last == value,
        orElse: () => throw AssertionError('Enum "$T.$value" does not exist.'),
      );

  T? fromOrNull(String? value) => (value == null) ? null : from(value);
}

Use it like this:

Day day = Day.values.fromOrNull('saturday');

But it would be better if we could write:

extension EnumExtension<T extends enum> on List<T> {

Why can't we write T extends enum?

[Levi-Lesches]

Because there currently is no such Enum class that all enums extend from