proposal: consider_const_constructor

[KyleFin]

consider_const_constructor

Description

Classes with no non-final fields may benefit from defining a const constructor.

Details

https://dart.dev/guides/language/effective-dart/design#consider-making-your-constructor-const-if-the-class-supports-it

Kind

Suggest potential optimization. Make authors deliberately choose to use const OR ignore lint. Point to useful Effective Dart reference to help them decide.

Bad Examples

class MyException extends Exception {}

class Square {
  Square(this.sideLength);
  
  Square.fromRadius(double radius) : sideLength = 2 * radius;

  final double sideLength;
}

class Square {
  Square(this.sideLength, this.color);

  final double sideLength;
  final Color color;
}

Good Examples

// Add a const constructor
class MyException extends Exception {
  const MyException();
}

// Make an existing constructor const
class Square {
  Square(this.sideLength);
  
  const Square.fromRadius(double radius) : sideLength = 2 * radius;

  final double sideLength;
}

// Explicitly ignore lint
class Square {
  // ignore: consider_const_constructor
  // Reason: we may someday change color to a getter.
  Square(this.sideLength, this.color);

  final double sideLength;
  final Color color;
}

Discussion

Background

I came upon this when reviewing some code using bloc. I assumed the default constructor was const and almost suggested removing the const constructor from an event class:

class TimerEnded extends EndingEvent {
  const TimerEnded();
}

// What I almost suggested:
class TimerEnded extends EndingEvent {}

I investigated more and learned that the default constructor is not const. Some resources I came across that helped me better understand why that's the case and when to use or not use const include:

• dart-lang issues const Constructor parameters are never considered const language#2000 (comment) and Constant constructor call should be legal in another constant constructor definition. language#823
• Language Tour and Effective Dart
• Existing lints: prefer_const_constructors_in_immutables suggests defining const constructor, prefer_const_constructors suggests using const constructor.
• https://stackoverflow.com/a/57618161
• https://medium.com/nerd-for-tech/flutter-performance-analysis-of-const-constructor-d2a72fd8a043

Considerations

• Should lint just check that at least one const constructor exists? Or that all defined constructors are const?

  • In Square.fromRadius example above, should making one constructor const satisfy the lint check, or should both constructors be required to be made const (or ignored)?
  • Does lint / ignore apply to individual constructors or to the entire class? Or both?
    • I'm not sure, but I think the check would apply to each constructor and we could have individual or entire class ignores.

• We could have a quick fix to create const constructor (if no constructors are defined) or make an existing constructor const, but it may be better to NOT have a quick fix so authors don't accidentally agree to maintaining a const constructor in their public API.

  • The intent of this lint is to remind authors to be intentional and guide them in deciding whether or not they want to use const.

• Is it worth having this lint?

  • Because it can't provide authoritative suggestions, I think this lint (if it's created) should be optional.
  • I'm not familiar with the actual performance gains, and it will depend on the app, but this seems like a helpful reminder for large, enterprise-grade codebases where good local decision making could add up to significant performance improvements.

• This lint could also suggest annotating class with @immutable. (consider_const_constructor lint would be similar to prefer_const_constructors_in_immutables).

Discussion checklist

• List any existing rules this proposal modifies, complements, overlaps or conflicts with.
• List any relevant issues (reported here, the SDK Tracker, or elsewhere).
• If there's any prior art (e.g., in other linters), please add references here.
• If this proposal corresponds to Effective Dart or Flutter Style Guide advice, please call it out. (If there isn't any corresponding advice, should there be?)
• If this proposal is motivated by real-world examples, please provide as many details as you can. Demonstrating potential impact is especially valuable.

[a14n]

• This lint could also suggest annotating class with @immutable. (consider_const_constructor lint would be similar to prefer_const_constructors_in_immutables).

I'd rather go in this direction. I'd prefer an add_immutable_annotation lint that trigger on classes with only final fields. Thus there would be no overlapping with other lints and it could easily be used together with prefer_const_constructors_in_immutables.

[incendial]

Available in DCM https://dcm.dev/docs/rules/common/prefer-declaring-const-constructor/