-
Notifications
You must be signed in to change notification settings - Fork 63
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
iter.Seq and naming changes #44
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be nice to have the following methods available:
These would line up nicely with the newly implemented
All
,Keys
andValues
functions in the standardmaps
package. Adding the twoiter.Seq
methods also allows for compatibility withslices.Collect
.Unfortunately,
Keys()
conflicts with the existing pre-iterators method and would require a major version change (or a different name). For the long-term I think the package would benefit from this consistency with the standard library. Also, the current version of theKeys()
method can be inefficient on large maps and moving to an iterator by default instead is a good API improvement IMO.Some other points:
All()
would be identical to the currentIterator()
method, but again, would be more idiomatic.Values()
was never implemented previously so no problems adding this.ReverseIterator()
maybe we should haveAllFromFront()
andAllFromBack()
instead. This is both idiomatic and consistent with the naming in this package.All()
could be an alias forAllFromFront()
.I understand that a major API change isn't always desirable, but I believe these changes will benefit the design in the long-term. I've created a branch with the proposed changes in my fork.
The text was updated successfully, but these errors were encountered: