Warn on capture of mutable variables by escaping lambdas

[YuliaKorolenko]

This is a discussion of the design proposal for warning on the capture of mutable variables by escaping lambdas. The current full text of the proposal is available here.

We are sharing it to collect feedback on the diagnostic rules, migration strategy, and related concerns.

[kyay10]

Personally, I don't even think @AllowEscapingVarCapture is needed. For tiny cases, the user can suppress the warning. For more involved cases, it probably makes more sense to make some data class StartedAt(var time: Int) and use that instead.

[CLOVIS-AI]

I agree. I think suppression works well, is already known by users, and has good IDE integration, so it's sufficient here.

[YuliaKorolenko]

I agree that suppression is enough from a technical point of view.
Our main reason for considering @AllowEscapingVarCapture is visibility. It marks the variable as something that requires attention, instead of hiding the warning with a suppression.
In practice, not all such cases are large enough to deserve a wrapper class. Code can be easy to read and the user knows the execution order from the surrounding API or logic, which can't be proven by compiler. It seems, that for those cases a local marker on the variable may be more honest and easier to notice than a general suppression or wrapper class.

[CLOVIS-AI]

A large share of them, about 35%, comes from lambdas that are effectively called in place, but the corresponding functions do not declare with a callsInPlace contract.

Given that the main "fix" when such a warning is encountered will be to mark the function as callsInPlace, which is experimental, but there is another KEEP for stabilizing it (#491), should this KEEP be ordered to be released just after or at the same time as the local keep?

I would find inconvenient to migrate lots of code to callsInPlace to immediately after re-migrate it to local.

[YuliaKorolenko]

Our current plan is to introduce the warning with the mentioned allowlist, so there is no need to use experimental callsInPlace. Then we plan to introduce local modifiers and then remove allowlist.

[CLOVIS-AI]

Personally, I don't find the showcased behavior strange, as they match the consequences of capturing mutability.

All the use-cases for that I have come across are already covered by the "specific rules", so this warning will not negatively impact me.