Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

Good point. The same is true for the C-style for loop BTW. https://play.golang.org/p/58jwveiywB Using an explicit boolean flag for signaling success avoids this trap. > On 2. Aug 2017, at 10:30, tom.pa...@centralway.com wrote: > > A side effect of this approach is that the index after the range

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

A side effect of this approach is that the index after the range loop will be zero if slice contains zero or one elements: https://play.golang.org/p/F7lLZ5wcuv This means that code using the index after the range will need to re-test whether the slice was empty to avoid a potential panic. On

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

That’s actually what I meant to indicate in the last paragraph (emphasis added by me): > The code in the Reddit post takes advantage of the fact that the last > increment of the C-style loop can be observed outside the loop, But thanks for providing a clarification. I see now it has not been cl

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

This is actually a really good point, thanks :) On Wed, Jul 26, 2017 at 1:37 AM, Chris Manghane wrote: > Hmm, well I can't give better reasoning off the top of my head, but I > still have to wonder why you expect the behavior of those constructs to be > the same, particularly. Imagine, you would

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

Hmm, well I can't give better reasoning off the top of my head, but I still have to wonder why you expect the behavior of those constructs to be the same, particularly. Imagine, you would like to capture both the iteration variable and the value itself, for example: var i, v = 0, "" for i, v = ran

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

Its likely this is because the idx in a range is just that, its the index of the processing element and not a loop iteration variable. As range never processes an element past the end of the slice, there's no way for it to get set to N, hence the difference in semantics from a normal for i :=

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

On Wed, Jul 26, 2017 at 12:52 AM, Chris Manghane wrote: > This is mentioned directly in the language specification under For > statements with range clause : > > For each entry it assigns iteration values to corresponding iteration >> variables if present a

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

This is mentioned directly in the language specification under For statements with range clause : For each entry it assigns iteration values to corresponding iteration > variables if present and then executes the block. and > For an array, pointer to arra

[go-nuts] Reasoning behind behavior of range, when index is maintained

Hey, someone shared [this question]( https://www.reddit.com/r/golang/comments/6paqc0/bug_that_caught_me_with_range/) on reddit. I must say, that I'm surprised by the behavior myself. I would have expected for i = range v to be semantically equivalent to for i = 0; i < len(v); i++ and don't really