Allow side-effect-free functions to be called at compile time (in constants)

[Hixie]

I have a class in Flutter (Flow) that takes a List<Widget> and passes a new list to its superclass constructor, the new list consisting of the incoming list mapped in a well-defined manner (each entry is wrapped in an instance of another class). All the information is available to evaluate this entire operation at compile time, and being able to do it then would allow big performance wins (because it would allow us to build the entire widget subtree once as a constant, which would then be == to itself each time it was referenced and thus we could avoid doing any work rebuilding that part of the tree).

[lrhn]

There are limits to what operations we can reasonably allow as compile-time constant operations.
I don't see applying a map operation to a constant list as something that we will allow. You don't get to iterate at compile-time. You don't get to call arbitrary function.

Even if we are able to declare some kind of "side-effect free" functions (which will probably have to be just a return followed by a "potentially const function"), and we allow calling these at compile time, with some way to avoid recursion, then you still won't be able to iterate a list.

Could you define what behavior your really need, not in terms of const (which is a hodge-podge of features - immutability, evaluate-once and canonicalization) but, perhaps, in terms of those individually.
Do you need immutability? Do you need canonicalization (sounds like it)?

[Hixie]

The key feature is being able to run build functions many times, and be confident that the leaf subtree that is built the same way each time will be considered == very fast when we compare it to the last one.

So for example if you have a dialog box that always shows the same message, then while the dialog box is being animated onto the screen, the entire subtree representing the contents of the dialog should cost nothing to display. Ideally, the entire thing would be pre-built at compile time and just inserted when we display the dialog box. Sometimes, building these subtrees requires some manipulation, like wrapping every item in a list with another, or checking for nulls, or whatever.

We get huge wins if we can avoid walking the tree of widgets when it "hasn't changed". The problem is that it's typically very difficult for us to tell that it hasn't changed, since we return new instances each time.