proposal: math: add Iter

[carnott-snap]

background

I have found that over a sufficiently large sample, c style for loops, for v := 0; v < 25; v++ {}, can introduce iterator and comparator bugs. As such I prefer for range [N]struct{}{} {}, or for range make([]struct{}, N) {} for N that is not const, as suggested in #36308 (comment). Unfortunately may people have found this syntax confusing, so I have taken to using iter.N, which uses the make form above, cleans up the syntax, and has a godoc explaining what is going on. But @bradfitz "encourage[s] [people] not to depend on this" and calls it out as "not ideomatic", despite the comment above. As such, I would like to have a discussion about including this to the stdlib.

impl

package math

// Iter returns a slice of n 0-sized elements, suitable for ranging over.
//
// For example:
//
//    for i := range math.Iter(10) {
//        fmt.Println(i)
//    }
//
// ... will print 0 to 9, inclusive.
//
// It does not cause any allocations.
func Iter(n int) []struct{} { return make([]struct{}, n) }

alternatives

nop

We can always do nothing, but I think this syntax is reasonable and improves safety and readability of trivial loops. Clearly we still need the c for syntax for non-trivial cases.

inline

If desired, this could be implemented in a way that the compiler more fully inlines it, especially in cases where the index is unused.

names

I am happy to have this be named something different or live in a different package. math seemed like a decent fit, since there is no numbers, ints, or iter package, and I did not want the stutter of for range math.Range(10) {}, but it would clearly indicate where it was intended to be used.

[randall77]

Might have some overlap with #43557

[mvdan]

I have found that over a sufficiently large sample, c style for loops, for v := 0; v < 25; v++ {}, can introduce iterator and comparator bugs.

Do you have any data or examples to back this up? They are perhaps a bit verbose and easy to mistype if you're not used to the idiom, but in practice I can't remember the last time I saw a bug caused by them directly.

[carnott-snap]

This seems hard to get good numbers on, and all my anecdotes are proprietary. It is mostly off by one errors, and it is not a deluge, but because iter.N feels like all the other range loops that tends to help with intuition.

[rsc]

This is a language change by another name.
We have a way to write loops.
You are welcome to prefer other ways,
but we don't need to provide a second standard way in Go itself.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[mdempsky]

I think this is a cute API, but (1) it seems inappropriate for package math (every existing function in package math has to do with floating point operations), and (2) there's no reason it needs to be in the standard library anyway (e.g., it doesn't expose any new types that separate modules need to agree on for interoperability).

[cristaloleg]

Also there is a lib for that, no need to change the language 😉 https://github.com/bradfitz/iter

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[bcmills]

I agree that the three-part for loop is awkward and error-prone (compare #24282), but I also agree that the math package (and the clever []struct{} hack!) doesn't seem like an appropriate long-term fix.

Personally, I hope that after generics land we may get a more holistic “iterator” API, and then we can provide a standard iterator for arithmetic sequences — this seems like a cleaner fit for a future iterators package than for math.

[cristaloleg]

Regarding iterator #43557

[rsc]

No change in consensus, so declined.
— rsc for the proposal review group