You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But final Foo foo = const Foo()..resolve(); is ok, and const Foo foo = const Foo(); foo.resolve(); are both ok. I would expect the compiler to desugar the failing version into the last version there.
The text was updated successfully, but these errors were encountered:
I don't think this is a duplicate of #542, but it is similar.
The reason this program does not compile is that Foo()..resolve() is not a compile-time constant expression. It cannot be because calling a method never is.
The problem is not (as in #542) that the initializer refers to the new variable foo before it's initialized. There is also no risk that the const Foo() object is seen in an uninitialized state because it is immutable when created.
Rather, the problem is that const declarations really do not occur as part of the normal evaluation flow.
For a local variable, we could perhaps find a way to split Foo()..resolve() into a constant part and a run-time part which is evaluated ... every time the declaration is evaluated? Even if we find a way to specify it meaningfully, it's a very specialized feature which is unlikely to pay for its own complexity cost.
It would not work for a top-level const variable. If you did const foo = Foo()..resolve(); at top-level (or as a static), it's very, very unclear when and how often the resolve would get called.
I'm not sure if this is a bug or not, but it seems strange to me. The following program will fail to compile:
But
final Foo foo = const Foo()..resolve();
is ok, andconst Foo foo = const Foo(); foo.resolve();
are both ok. I would expect the compiler to desugar the failing version into the last version there.The text was updated successfully, but these errors were encountered: