Dart：使用const构造函数有不利之处吗？

Question

There is an analyzer/lint check to warn me when it is possible to use a const constructor: https://dart-lang.github.io/linter/lints/prefer_const_constructors.html

(ie. using final a = const A(); instead of final a = A(); )

I think to understand the advantages (there will only ever be one instance with the same constant values for a const constructor). But why isn't this the default? Since dart 2 the new can be omitted, so why didn't they change the definition of creating a new instance which can be created const simply as const instead of new ? I assume there must be some disadvantage to having everything const ?

(for example in a constant context like const [A()] it is actually the same as const [const A()] , so why not everywhere)?

Answer 1

so why didn't they change the definition of creating a new instance which can be created const simply as const instead of new ?

If you mean why doesn't final a = A(); automatically assume const A() if A has a const constructor:

1. Sometimes it is automatic:

    const a = A(); 

   in which case A 's constructor is being invoked in a const context and doesn't need an extra const qualifier on the right-hand-side.

2. An explicit const expresses intent . For example, suppose you had:

    final a = A(B()); 

   where A and B have const constructors. Later, somebody makes a change:

    final a = A(C()); 

   where C does not have a const constructor. If const were automatic, then you would have no idea that a is no longer const . Maybe that's okay, but it also could suddenly have a negative impact on your application's performance, and without an explicit const qualifier, the impact of a local change could have a much wider scope than expected. (That said, explicit const qualifiers and automatically adding them aren't mutually exclusive.)

3. const can have downsides. const creates compile-time constants. If you have:

    final a1 = A(); final a2 = A(); 

   identical(a1, a2) is not true. If const A() were implicit, then identical(a1, a2) would be true, and maybe that's not a property that the code intended to have.

4. I think that compile-time constants live forever. The whole point is to have an object that can be reused instead of re-constructing it. The flipside is that they can't really be destroyed easily.