Update range-iteration concept docs - #3060
Conversation
|
|
||
| You now have the knowledge on how to iterate a slice, or a map, in Go. | ||
| In Go, `range` iterates over slices, arrays, maps, strings, and channels. | ||
| Each iteration yields two values: the index (or key) and a copy of the element at that position. |
There was a problem hiding this comment.
This isn't broadly true. It's true for ranging over slices, arrays, maps and strings. It's not true for channels, iterators and range int. It probably shouldn't be stated as generally true.
I think it's generally true that range yields one or two values. We probably want to mention iterators. They're used a fair bit in, say, the strings package, eg strings.FieldsSeq() or strings.SplitSeq()
Co-authored-by: Isaac Good <IsaacG@users.noreply.github.com>
| @@ -1,8 +1,10 @@ | |||
| { | |||
| "blurb": "Go has a special \"for range\" loop to easily iterate over collections of data.", | |||
| "blurb": "The for range loop iterates over slices, arrays, maps, strings, and channels.", | |||
There was a problem hiding this comment.
...and iterators? Or leave it vauge?
There was a problem hiding this comment.
Probably should make it vague rather than enumerate everything. The previous blurb was incorrectly vague and lost some meaning. What is a collection of data even? I think the elevator pitch here would be something along the lines of "the for range syntax can repeat a block of code in a variety of ways." Then in the document, we discuss what that means for the different ways.
| # About | ||
|
|
||
| You now have the knowledge on how to iterate a slice, or a map, in Go. | ||
| In Go, `range` iterates over slices, arrays, maps, and strings. |
| In Go an unused variable will raise an error at build time. | ||
| Sometimes you only need the value, as per the first example: | ||
| Go will not compile if a variable is declared but never used. | ||
| If only the value is needed, assign the index or key to `_` to ignore it. |
There was a problem hiding this comment.
This line should probably be moved after the codeblock.
| ~~~~ | ||
|
|
||
| ## Iteration omitting key or value | ||
| ## Omitting Index or Value |
There was a problem hiding this comment.
Should this come after all the range-types? Should we cover ranging over strings? Channels? Maybe mention channels are a later concept?
IsaacG
added
x:action/improve
2 participants
Related to #3042