Yes, very tricky stuff. I've replied on the issue - it seems best to keep
discussion in one place.
Thank you very much for opening the issue!
On Mon, Aug 14, 2017 at 2:35 PM, Ian Lance Taylor wrote:
> On Fri, Aug 11, 2017 at 4:38 PM, Ian Lance Taylor wrote:
> > On Thu, Aug 10, 2017 at 1:43 PM,
On Fri, Aug 11, 2017 at 4:38 PM, Ian Lance Taylor wrote:
> On Thu, Aug 10, 2017 at 1:43 PM, wrote:
>>
>> Yes, it makes sense that it would be impossible to really check at that
>> level. What surprised me was that this does not trigger vet:
>>
>> for i := range slice {
>> go f(i)
>> _ =
On Thu, Aug 10, 2017 at 1:43 PM, wrote:
>
> Yes, it makes sense that it would be impossible to really check at that
> level. What surprised me was that this does not trigger vet:
>
> for i := range slice {
> go f(i)
> _ = 1
> }
>
> Yet this does trigger vet:
>
> for i := range slice {
>
Yes, it makes sense that it would be impossible to really check at that
level. What surprised me was that this does not trigger vet:
for i := range slice {
go f(i)
_ = 1
}
Yet this does trigger vet:
for i := range slice {
_ = 1
go f(i)
}
Is there something special about the las
If you have a loop like:
for i := range slice {
f(&i)
}
There's no way to know whether f launches a goroutine that captures the
loop variable without also evaluating the body of f and potentially every
function directly or indirectly called by f. If i escapes into a global
variable, you also
I've noticed that cmd/vet's rangeloop check, which warns you about binding
to range loop variables in function literals which are launched with 'go'
or 'defer', is more limited than I thought:
https://github.com/golang/go/blob/d5ad7793d610bddfb3e7e09b8dafa0b0837f0cb2/src/cmd/vet/rangeloop.go#L6-
