TL;DR

The proposal is to limit let-generalization to

• values that are syntactically functions
• values that are syntactically number literals

All other values bound to an identifier that have free type variables will not be generalized, leaving their free variables to be resolved to exactly one concrete type based on future usage. For the purposes of this document, we call such type variables “weak” while they have not been yet resolved to a concrete type

This proposal also prevents modules from exposing values with still-weak type variables. Now, a module may only expose values that are explicitly a concrete type, or explicitly generalized. In practice, this means that you can expose

• number literals, with or without type annotations
• syntactic functions, with or without type annotations
• non-literal number values only with type annotations, or as a thunk
• tag union values only with type annotations, or as a thunk
• non-syntactic functions only with type annotations

All of these restrictions with come with new, friendly error messages.

Summary

Let-generalization is a great feature of Roc that allows you to use values polymorphically, so that you can have a function that operates over many datatypes, or define numeric constants that can be used as many different concrete number types without needing conversion.

However, today,

• Roc’s let-generalization is too powerful, and can lead to serious problems in the runtime semantics of a program
• Roc’s compilation scheme for arbitrary let-generalized values is also somewhat computationally-expensive, and limiting its scope would improve compile-times in general
• The current form of let-generalization means that there is a certain class of programs that we successfully type-check, but whose compilation are open technical questions. Limiting let-generalization is one solution to those questions.