analyzer could suggest to put class const

[EArminjon]

class Welcome {
  Welcome(this.number);

  final int number;
}

void main() {
  Welcome(1);
}

Welcome class can be const, analyzer could suggest it ;).

[RohitSaily]

Agreed, and to add, this should not only be a linter rule but should also be a standard linter rule since it is generally recommended to define things as const when possible, as early as possible

[lrhn]

I'll disagree here.
You should make things const if you intend them to be used as constants, not just because they can.

Making a class const makes it a breaking change to remove the const in the future.

This class can be const as written, because it's pretty basic.
If tomorrow it wanted to add a welcome message which includes the time when the instance was created, so it needs to store a DateTime which has no const constructor, it would have to remove the const again.

That would be a breaking change, anyone who uses const Welcome(42) today will have to update their code to remove the const.

That pain will be avoided by just not making it const to begin with.

Some classes can and should be const. Others can and shouldn't be const. Only they author knows which is which.

[EArminjon]

I'll disagree here. You should make things const if you intend them to be used as constants, not just because they can.

Making a class const makes it a breaking change to remove the const in the future.

This class can be const as written, because it's pretty basic. If tomorrow it wanted to add a welcome message which includes the time when the instance was created, so it needs to store a DateTime which has no const constructor, it would have to remove the const again.

That would be a breaking change, anyone who uses const Welcome(42) today will have to update their code to remove the const.

That pain will be avoided by just not making it const to begin with.

Some classes can and should be const. Others can and shouldn't be const. Only they author knows which is which.

I understand the point, but it doesn't sound bad (maybe i'm wrong and didn't well understand a point). If my class was at beginning 'simple' and 'determinist', by adding a DateTime logic it will break the initial statement. It's a fair breaking change if that's happen in my apps / packages.

Also this proposal should be part of a linter to be 'optional' and not a default standard for those who don't want it.

[RohitSaily]

I'll disagree here. You should make things const if you intend them to be used as constants, not just because they can.

Making a class const makes it a breaking change to remove the const in the future.

This class can be const as written, because it's pretty basic. If tomorrow it wanted to add a welcome message which includes the time when the instance was created, so it needs to store a DateTime which has no const constructor, it would have to remove the const again.

That would be a breaking change, anyone who uses const Welcome(42) today will have to update their code to remove the const.

That pain will be avoided by just not making it const to begin with.

Some classes can and should be const. Others can and shouldn't be const. Only they author knows which is which.

Good point, it can encourage defining things in a restrictive manner. It definitely should not be a standard lint because of this

---

Also this proposal should be part of a linter to be 'optional' and not a default standard for those who don't want it.

I agree this could still be useful as an optional lint

It serves as a reminder to make a type const as early as possible which is useful for preventing future changes incompatible with const (eg introducing a stored variable property). This is especially useful when one wants to use const as much as possible

[bwilkerson]

I don't think the value of the proposed lint is high enough to make this something we would implement given our currently high bar for adding new lints.