Skip to content

consider a use_enums lint to encourage migration from enum-like classes to enhanced enums #58624

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #58582
pq opened this issue Jan 24, 2022 · 3 comments · Fixed by dart-archive/linter#3253
Labels
devexp-linter Issues with the analyzer's support for the linter package legacy-area-analyzer Use area-devexp instead. linter-new-language-feature

Comments

@pq
Copy link
Member

pq commented Jan 24, 2022

No description provided.

@pq pq changed the title consider a prefer_enums lint consider a prefer_enums lint to encourage migration from enum-like classes to enhanced enums Jan 24, 2022
@jacob314
Copy link
Member

Like other language feature migration lints, this is a lint that I would want to have ship with a quickfix to make it easy for users to learn how to do the migration.

@bwilkerson
Copy link
Member

As a starting point we can probably use the existing definition of an enum-like class to define which classes to lint, but we might need to make some adjustments. For reference, the documentation currently states:

An enum-like class must meet the following requirements:

  • is concrete,
  • has no public constructors,
  • has no factory constructors,
  • has two or more static const fields with the same type as the class,
  • has no subclasses declared in the defining library.

We probably need to add at least one additional criteria:

  • is a subclass of Object (because enum's can't extend other classes).

If enums aren't allowed to have mixins then we'll also need to check that the class being linted doesn't have a with clause.

Are there other criteria we need to check for?

@pq
Copy link
Member Author

pq commented Feb 26, 2022

Are there other criteria we need to check for?

My first cut implementation settled on a slight variation on the list above. (See PR.)

TL;DR:

Candidates for enums are classes that:
  * are concrete,
  * are private or have only private generative constructors,
  * have two or more static const fields with the same type as the class,
  * have generative constructors that are only invoked at the top-level of the
    initialization expression of these static fields,
  * do not define `hashCode`, `==`, `values` or `index`,
  * do not extend any class other than Object, and
  * have no subclasses declared in the defining library.

As mentioned in the WIP PR, the index restriction isn't strictly necessary and I'm open to expanding the check to handle cases where classes use an index in an enum-compatible way.

@pq pq changed the title consider a prefer_enums lint to encourage migration from enum-like classes to enhanced enums consider a use_enums lint to encourage migration from enum-like classes to enhanced enums Mar 1, 2022
@devoncarew devoncarew added devexp-linter Issues with the analyzer's support for the linter package legacy-area-analyzer Use area-devexp instead. labels Nov 19, 2024
@devoncarew devoncarew transferred this issue from dart-archive/linter Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devexp-linter Issues with the analyzer's support for the linter package legacy-area-analyzer Use area-devexp instead. linter-new-language-feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants