The “Loopvar” experiment looks like backward compatibility nightmare.
As confusing as the existing behaviour could be, the new experiment is asking for trouble.
Everyone that I've ever talked to who went through the transition has a similar story. In practice no one even incidentally relied on the old behavior. Go rolling it out as an experimental opt-in feature is a good idea, but it'll probably turn out to be unnecessarily cautious and they could have gotten away with just unconditionally enabling it.
Seems like they thought about that. I think it's a good change.
Way back when C# actually went through that change unconditionally (LangVersion was not a thing yet), and there was barely any breakage.
For `for ...; ...; ...` loops, personally, I think the conclusion is the inverse.
One breaking case:
func main() {
defer println()
for counter, i := 0, 0; i < 3; i++ {
defer func() {
counter++
print(counter)
}()
}
}
More surprising cases: https://github.com/golang/go/issues/60078#issuecomment-15443...
Have you proved it?
If you want to argue, you really need to show an example of where the change causes a bug in any scenario that matters. With a real, preexisting, program.
I totally disagree with your logic. I think you don't have the right logic here.
At least, the proposal should be accepted when the experiment period has lasted for a year. But now, the proposal has been accepted before the experiment period started. Is it weird?
If you want evidences, please read my recent tweets: https://twitter.com/go100and1
My logic: every domo code matters.
Proving the existence of a program that contains code which will become buggy is easy: share the code. Show actual program code, not a hypothetical; nobody is saying the experiment doesn't change behavior, people are saying it only changes behavior that doesn't matter to real world code.
On real world code discovered so far, the experiment would fix bugs.
It is not my (and all other Go programmers') responsibility to do this. Here, I just shows the possibility that the proposal will do harm, and help others to find the broken cases easily. However, surely, Go programmers, in their spare time, can help the proposal's supporters to do this. But, again, it is strange that the proposal has been accepted before such attempts are made. :D, so weird.
And, please read my tweets, there are several factors which are unrelated to finding broken code. In fact, the change will lead to more error-prone, instead of less error-prone.