This looks like a dup of #16520. The examples are slightly different (go/defer versus &), but I believe the root problem is the same.

@mvdan I actually wrote this as a comment to that issue before submitting this one instead :)

While the problems do overlap, #16520 is about capturing, which is not the issue here. I think the main difference is that there are many legitimate reasons to capture a loop variable inside a function literal (at least with the go statement).

As I try to argue here, taking a range variable address is much more unlikely to be useful - in part because you can capture the original variable. Also, fixing "false positive" cases is trivial using the mentioned replacements. This will not be the case if you generalize the problem.

Ah, I think I see what you're after then. I take it that when you say "taking an address" you mean whenever the compiler takes a variable's address, even if it wasn't explicit in the code via & - such as in a go func.... Is this correct?

As in the examples, I do mean it to be explicit in the code with &. Note that none of the examples use captures, which is why I think this is a different issue. Also, the other issue is much more difficult to solve than this one is (because the amount of legitimate use cases is smaller).

There are no warnings but we could think about disallowing this entirely in Go 2. Leaving for that.

@rsc I used the word "warn" because it seemed to me to be conventionally used by other issues on go vet. I did mean "rejected" by go vet.

I have a simple patch that I wanted to try and submit tonight (UTC+1 time) :)

It's too invasive to reject in vet. It fails the "precision" test in cmd/vet/README.

Not being able to take the address of an addressable thing turns the "addressable" concept into something very weird. Also:

for _, bigValue := range bigValues {
        foo(&bigValue)
}

is completely reasonable code avoiding making another copy of bigValue when foo just reads its argument.

@rsc How is it determined if it fails the test? I've tried to run my patched tool on a bunch of random projects and found mostly cases which are definitely "worth examining" as the precision test states. Maybe the test could be disabled by default if it becomes too noisy in an existing project?

@cznic As bigValue is already a copy of a value in bigValues, I think this is actually a case where he check would have been helpful to make you not copy the value:

for idx, _ := range bigValues {
        foo(&bigValues[idx])
}

Alternatively, you would just have to define bigValue (and a pointer to it) outside of the loop as suggested earlier.

There is plenty of correct code it would disallow. That's not OK. See @cznic's comment for one example. I am sure there are more, even if not in your own code base. That's why it's really a spec change.

foo(&bigValues[idx])

Iff bigValues is a slice/array.

The most common false positive I found so far is return &loopVar, which would be easy to allow. I will try to gather some data on the amount of false positives.

There is nothing wrong with taking the address of a range variable if you don't save the pointer across loop iterations. And, this restriction doesn't fix the problem of referring to a range variable in a closure, which is if anything more likely to be problematic. Closing.