Dart enum toString is too verbose

[jacob314]

Flutter can't use the default toString() for enum types as it is too verbose and instead has to carefully call a describeEnum(entry) helper whenever an enum entry is displayed in a message.
The describeEnum helper strips out the enum type from the result of calling entry.toString().
It would be nice if the default toString() for enum just displayed the enum value or if the enum class provided a toStringShort() method that returned just the enum value.

Note that you someone who really wanted to display Type.entry could just write

'${entry.runtimeType}.${entry}'

Example of current behavior:

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

main() {
  assert(Day.monday.toString() == 'Day.monday');
  assert(describeEnum(Day.monday) == 'monday');
}

[lrhn]

Using "${entry.runtimeType}.$entry" would be assuming the behavior of Type.toString which is not specified anywhere.
I would really, really like if we could get away from having toString that somehow reflects on source names, like the toString of enums, Type and Object. It's nice for debugging, but it does require retaining source names at runtime, and that's a can of worms when people start using it.

As for enums, the Dart enum design is very plain, enum instances are not carrying any value except their distinguishing index, and that includes a string of their source name. Their toString is meant to make them distinguishable when debugging, also from other enum types that may share an element name, and not to somehow be a reflection of their name.

It seems that you actually do want a string that matches their declared name, and even as a string, not a symbol. That's two steps removed from the actual declaration, and not something that is generally desirable.

That said, we did chose to provide the name in the toString so it's annoying that there is no other way to get it. We could add a name getter to enum instances, but that would preclude using name as an enum element name – no enum AddressPart { name, address, zip, city, country; } enums allowed – so it's a breaking change.
Co-opting the toString is as breaking, because people (like you) are already using it.

[jacob314]

To clarify, Flutter uses the short name as part of debugging messages so symbolizing names in production would probably be acceptable. The debugging messages can get very large and need to be easy to read so showing the class name as well as the entry name doesn't work.

I agree that adding a name getter is bad for the reasons you suggest.

To avoid a breaking change we could add a top level method to the core library that gets the name of an enum entry. E.g. enumEntryName(Object o)

Using a more verbose name would also be reasonable. We can track the number of occurrences of the verbose name in pub packages to verify the impact of the breaking change will be small. For example, I would guess than toStringShort is not used as an enum entry in any existing package.

[rakudrama]

1. I would like to avoid symbolizing anything - in dart2js, the symbols cause allocations at startup. 2. Minified dart2js output contains many copies of the enum class name embedded in the 'name' strings, e.g. "Day.monday", "Day.tuesday" etc. The "${entry.runtimeType}.$entry" approach would print minified types, e.g "z6.monday" 3. The VM misses an opportunity to 'safe-print' enum names. For example, d.cancel() prints NoSuchMethodError: Class 'Day' has no instance method 'cancel' Receiver: Instance of 'Day' but could 'safe-print' enum values instead of or in addition to "Instance of 'Day'" 4. dart2js could also safe-print enum values.

…

On Tue, Jun 27, 2017 at 9:13 AM, Jacob Richman ***@***.***> wrote: To clarify, Flutter uses the short name as part of debugging messages so symbolizing names in production would probably be acceptable. The debugging messages can get very large and need to be easy to read so showing the class name as well as the entry name doesn't work. I agree that adding a name getter is bad for the reasons you suggest. To avoid a breaking change we could add a top level method to the core library that gets the name of an enum entry. E.g. enumEntryName(Object o) Using a more verbose name would also be reasonable. We can track the number of occurrences of the verbose name in pub packages to verify the impact of the breaking change will be small. For example, I would guess than toStringShort is not used as an enum entry in any existing package. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#30021 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAtleaXl8hkUmnBpHo46m1x5p7FbXElks5sISoZgaJpZM4OF62f> .

[lrhn]

We don't make it easy to recognize enum values as being so. There is no common type that enum classes evaluate to (unlike, say, Java where enum Foo implements Enum<Foo>).
If we did that, it's likely that Error.safeToString or similar methods could handle enums as well without needing a platform hook to recognize it as safe.

[jacob314]

Implementing an explicit Enum interface would help a lot. I don't think we lose much by defining an explicit Enum type as enums as defined now are already too typed to work well for JS interop. For js interop you would want enum values to just be int or string. @lrhn wrote:

…

We don't make it easy to recognize enum values as being so. There is no common type that enum classes evaluate to (unlike, say, Java where `enum Foo` implements `Enum<Foo>`). If we did that, it's likely that `Error.safeToString` or similar methods could handle enums as well without needing a platform hook to recognize it as safe.

[rakudrama]

What are the benefits of the type parameter in enum Foo implements/extends Enum<Foo> ?
There a cost to the type parameter (in dart2js the 'implements' clause is stored as metadata on the class).

[lrhn]

Looking at the Java implementation, the only two methods on Enum that uses the type parameter are:

int compareTo(E o)
Class<E> getDeclaringClass()

We don't need the getDeclaringClass and we haven't made enums comparable, so the type parameter doesn't currently give us a lot of benefit.

Another use-case of generic classes in general is to restrict to a sub-hierarchy (withWidgets(List<Widget> ...)) but since you can't subclass enums, the sub-hierarchy Enum<Foo> is equivalent to just Foo, so no advantage there.

We could just make enum a non-generic class that declares int get index.

So, unless we intend to add methods to Enum or allow non-trivial sub-hierarchies, I don't see any advantage in making it generic. It's needed only in cases where we want to treat multiple enum types in a generic manner, and where calling a method on the enum value itself should return or accept something of its own type. We don't have that problem.
If we wanted to make the enum entries comparable, we could do:

bool operator <(covariant Enum other);  // in Enum

and override it in each implementation (or cheat, since we probably don't allow anybody to implement Enum manually, so we can use the internal structure of the enum).

[alan-knight]

This also comes up with Intl. There's a select method that lets you choose from several alternatives. It's a natural fit for enums, but it's defined to accept only certain characters in select identifiers, and excludes ".". We could transform the result of the enum's toString(), but that gets pretty ugly.