Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: math: add Iter #44394

Open
carnott-snap opened this issue Feb 18, 2021 · 3 comments
Open

proposal: math: add Iter #44394

carnott-snap opened this issue Feb 18, 2021 · 3 comments
Labels
Projects
Milestone

Comments

@carnott-snap
Copy link

@carnott-snap carnott-snap commented Feb 18, 2021

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.

@gopherbot gopherbot added this to the Proposal milestone Feb 18, 2021
@randall77
Copy link
Contributor

@randall77 randall77 commented Feb 18, 2021

Might have some overlap with #43557

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Feb 19, 2021
@mvdan
Copy link
Member

@mvdan mvdan commented Feb 19, 2021

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
Copy link
Author

@carnott-snap carnott-snap commented Feb 19, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Proposals
Incoming
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants