3 ms·

The proposal has two parts, one is to change the semantic of "for-range" loops, the other is to change the semantic of traditional c-like "for;;" loops. The fi

by tapirl 3y ago

The proposal has two parts, one is to change the semantic of "for-range" loops, the other is to change the semantic of traditional c-like "for;;" loops. The first part is good and will fix your problem. However the second part will produce some surprises to many people.

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 ago
  see https://news.ycombinator.com/item?id=35912510 https://news.ycombinator.com/item?id=35912510
  - doctor_eval 3y ago
    Yeah - 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
      :)

by tapirl 3y ago

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 ago
see https://news.ycombinator.com/item?id=35912510 https://news.ycombinator.com/item?id=35912510
- doctor_eval 3y ago
  Yeah - 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
    :)