Optional Enum Type in Equality Checking

[MohiuddinM]

Introduction:

This proposal suggests making the enum type optional when performing equality checking in Dart. Currently, when comparing enum values, developers are required to explicitly specify the enum type, which can lead to verbosity and redundancy in code.

Motivation:

The motivation behind this proposal stems from the desire to enhance code readability and reduce redundancy in Dart codebases. Enum types are already known at compile-time and can be inferred by the Dart compiler in most cases. Requiring developers to specify the enum type explicitly during equality checking adds unnecessary verbosity to the code.

Example:

Consider the following scenario:

enum Status { pending, completed }

void main() {
  final status = Status.pending;
  
  // Current approach
  if (status == Status.pending) {
    print('Task is pending');
  }
  
  // Proposed approach
  if (status == .pending) {
    print('Task is pending');
  }
}

In the proposed approach, the enum type (Status) is omitted when checking for equality, leading to cleaner and more concise code.

Design:

The proposed design involves allowing developers to omit the enum type when performing equality checking, provided that the enum value is unambiguous within the scope.

Syntax:

The syntax for equality checking without specifying the enum type would be as follows:

if (enum_value == enum_constant)

If the enum value is unambiguous within the scope, Dart would infer the enum type implicitly.

Benefits:

1. Improved readability: Omitting the enum type in equality checking results in cleaner and more readable code.
2. Reduced redundancy: Developers no longer need to repeat the enum type when performing equality checks, reducing redundancy and improving developer efficiency.

Conclusion:

This proposal suggests making the enum type optional when performing equality checking in Dart, thereby enhancing code readability and reducing redundancy. By adopting this change, Dart developers can write more concise and expressive code without sacrificing clarity.

[MohiuddinM]

It is also possible to expand it to switch expressions

[lrhn]

Sounds like the same request as #357 or the more general #3616

[MohiuddinM]

Thanks for the info. I would close this in favor of #357