Compiler should try to make everything const

[feinstein]

I mainly use Dart for Flutter and declaring Widgets as const brings performance improvements. On the other hand it's boring to type const all the time, or verifying which constructors are const, or even having to fix a constructor call that just got broken because it was declared as const and now can't be evaluated at compile time.

A linter warning helps to remember to use const, but actually using them isn't much comfortable.

It would be amazing if the compiler could automatically understand what can be promoted to const and optimize the code as const behind the scenes.

[mateusfccp]

What about the cases where you don't want const? What do you propose?

[feinstein]

I tried to think about those cases but couldn't find any that I wouldn't want const. Could you give me some examples?

[mateusfccp]

Any case where you want your classes to be separate instances and refer to different objects although with the same parameters.

[feinstein]

Could you give me an example?

This sounds a bit like bad practice. The kind of thing Value Objects (built_value) try to solve.

[feinstein]

Maybe we can have noconst for those cases?

[mateusfccp]

Could you give me an example?

This sounds a bit like bad practice. The kind of thing Value Objects (built_value) try to solve.

In a OO context it is not a bad practice, although me myself never use it this way, as I usually program in a funcional way.

[lrhn]

One example is var token = Object();
Here you want to create a new unique object that is not equal to any other object. If that became var token = const Object();, the object would be canonicalized and equal to any other Object() anywhere in the program.

Also, what about [], which creates a new mutable list. I could be const, but then it would be immutable.
And then that can occur deep inside another object: var foo = Bar(Baz(Qux([])));. That too can be const if [] is const, and won't be const if [] is not const. Should it?

I guess that's cheating because [] actually creates objects with different behavior depending on whether it's const or not.
If we restrict it to invocations of const constructors with only const arguments, then there wouldn't be a difference in behavior, only in identity.
We toyed with this during the development of Dart 2.0, where we made new optional, but found it too risky.
A small and subtle change deep in an object construction expression could change whether the entire expression is constant. If you actually wanted the expression to be constant, but someone changed const someConstant = 42; to final someConstant = 42; and you use someConstant in your expression, then it would just silently stop being constant, and you would likely never notice.
That's why you have to ask explicitly for const, not just to document that it's what you intent, but also to allow the compiler to recognize that it's what you intend and warn you when it stops being true.

[feinstein]

I see... So could we have a shortcut for const? Like .Widget() or *Widget or &Widget or another leading character, just like _ works for private library members.

This could make things a lot more convenient and comfortable in Flutter. Also we would get a performance increase as more people won't ignore const for lazyness or readability/80 characters limit.

[jaddison06]

To offer my perspective on this within Flutter: I find const annoying when I'm rapidly prototyping w/ hot reload as I have to recompile to change something declared as const. For this reason I think automatically making everything const would be a pain, but it would definitely offer performance benefits in production.

[cedvdb]

it would definitely offer performance benefits in production.

I've seen that being claimed from time to time. Does it really have a non negligible impact ? Has someone done some testing ? Maybe one of the command can while in to shine some light on that

[feinstein]

Yes it does, specially for complex animations. Imagine you have to recreate a complex widget tree 60 times per second, with const you can optimize a lot of it.

[cedvdb]

Have you tested it ? Is there somewhere I can see the results ? I'm not trying to be condescending, I just would like proof of those claims. In my tests which could have very well been wrong, I didn't see a difference so I assumed it was a myth and preemptive optimisation. However my tests might have been faulty as I tried that while learning flutter, so very newbie to the language.

[feinstein]

I didn't, but I remember seeing something a while ago.

[jaddison06]

Just did a v small preliminary test with a few Text & Icon widgets, rebuilding the widget tree very fast. Bear in mind this was very minimal compared to the widget tree of a complete app. However, with Flutter's profile build I saw an average of about 5fps increase when using const. I'll see if I can write a more complete example later today.