Open iand opened 7 years ago
This is a language change so marking as a proposal for Go 2.
@iand This is somewhat vague a proposal. Can you elaborate a bit? For instance, how "deep" is the "freezing" of such assign-once variables? If I have a pointer or slice in an assign-once variable, can I still change the contents of the value pointed to or the elements of the slice?
I can imagine how to implement this for composite liberals, but it is harder for init functions—many creative ways to get bits of the structure to escape, particularly if it is a compile time check.
One nice thing about this for maps is that it would let the compiler substitute data structures optimized for lookups, which could provide very substantial speed-ups.
"repeated imports of a single package" — aren't packages only imported and initialized once in an output binary, thanks to the guarantee of no import cycles? Do c-archives/c-shareds/plugins each have their own separate copies of packages?
Mutable state held in package-level variables can be problematic for a few reasons, e.g. concurrency [edited to remove erroneous mention of multiple imports]
It would be useful to be able to declare a form of "assign-once" variable that can only have its value set via an initializer in the declaration or in a subsequent init function. Once all init functions have completed the value of the variable cannot be changed.
Some other languages use a special keyword to indicate this type of variable (e.g. pony uses let for assign-once variables and var for others)