As I explained in the original discussion, my only remaining concern (at the time) was whether "updating" the weak let capture when the original instance goes out of scope is thread-safe or not.
I am happy to hear that this is the case! So I don't see any problem with having weak let and give a (probably unqualified) +1.
As a matter of fact, these discussions show that perhaps the resulting mental model of forbidding it is not correct. I believe I even remember a student of mine being perplexed a bit, along the lines of: "Okay, it can become nil, but I am not the one mutating it?" (When explaining the syntax and reasoning behind it in the context of reference cycles I did use the, I assume, standard explanation of "it has to be a var because it can become nil")
Btw, the same can indeed be said by requiring var for read-only computed properties. On the one hand they are "variable" indeed as two subsequent accesses could give you "variable" results, but newcomers are sometimes thrown off because in spite of seeing the var keyword they cannot assign values to it. No personal anecdotes here, though (perhaps because this is usually explained a lot sooner when students just soak everything up without asking too many questions... maybe I need to slow down at the beginning...).
Is there a better way of doing it? E.g. some script that would check out a list of projects and try to build them with modified compiler.
It's an experimental feature, not the upcoming one. You are right, the proposal is to flip this unconditionally. My understanding was that it is specified in the text to let people know what feature to enable when testing the toolchain. If that's not a correct usage of the proposal template, I can remove it, or change wording to "Experimental Feature Flag".
