Today I allow const List and Map fields, but in order to set them you must call toImmutable in a way the compiler can check. This is a little awkward, and in some cases makes it hard to write natural code using null or more complicated expressions. I propose to have the compiler implement the toImmutable call automatically:

// today
const Int[] x := [1,2,3]              // not ok
const Int[] x := [1,2,3].toImmutable  // ok

// proposed
const Int[] x := [1,2,3]              // ok (implicit toImmutable call)

Same current restriction and proposal also applies to const Type fields.

I like that, that was always a bit cumbersome.

Looks good. I have wondered, though, why it's const and toImmutable as opposed to immutable and toImmutable or const and toConst?

why it's const and toImmutable as opposed to immutable and toImmutable or const and toConst?

Originally everything was just const (a long time ago in 2007). But it started to make sense to introduce two terms in our terminology. Immutable is the general concept of something which can't change out underneath you. Const is a special case of immutability which regard to class and slot modifiers. For example Lists, Maps, and Type can be made immutable, but they aren't const.