3 ms·
I hadn't seen that, but I've since read the comments from rsc and others and I'm curious why you think it will be a problem? From what I can gather (I'm too bu
by doctor_eval 3y ago
I hadn't seen that, but I've since read the comments from rsc and others and I'm curious why you think it will be a problem?
From what I can gather (I'm too busy/lazy/both to dive into the formalities), the for;; loop will have a new variable allocated at the start of each iteration, similar to the proposed range loop behaviour change. The strong argument for this is that you'd expect both loop forms to behave similarly; if they were to remain different, which would be the case of they didn't make this change, then the principle of least surprise would be violated.
However, reading the followup comments, some people seem to have missed that the value of the variable at the end of one iteration will be used to re-initialise the new variable at the start of the next iteration. This seems to mean that the usual semantics of a for;; loop will not change, other than if you're doing some really strange stuff, which doesn't seem to be the case when reviewing large existing code bases.
I had misgivings about the behavioural changes being triggered by the Go version number in go.mod, but rsc makes a good argument that any dependency change carries some risk, intentional or not.
- tapirl 3y agosee https://news.ycombinator.com/item?id=35912510 https://news.ycombinator.com/item?id=35912510
- doctor_eval 3y agoYeah - but I agree with rsc, it’s easy to come up with constructed examples of behaviour changes, much harder to come up with examples you’d find in production code. I mean - maybe you feel differently, but if I saw that code in a PR, I would reject it. It’s way too tricky for me.
- tapirl 3y ago:)