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

renaming take #270

Closed
bakkot opened this issue Mar 15, 2023 · 3 comments
Closed

renaming take #270

bakkot opened this issue Mar 15, 2023 · 3 comments

Comments

@bakkot
Copy link
Collaborator

bakkot commented Mar 15, 2023

Per discussion in this thread, some users infer/want that you can take multiple times from the iterator to get multiple chunks. But because exhausting the take subiterator closes the underlying iterator, you can't actually do that. That may be confusing if you're used to e.g. rust iterators.

We should probably rename it. My preference is to use limit, which is what Java calls it.

(And while we're at it we will probably want to rename drop to skip, since take is always paired with drop and limit with skip.)

Do read the discussion in the original thread. I wanted to open a separate issue so we could track it properly. cc @benjamingr

@michaelficarra
Copy link
Member

The committee decided today to not go through with the rename of take and/or drop. Closing.

@michaelficarra michaelficarra closed this as not planned Won't fix, can't repro, duplicate, stale Mar 21, 2023
@jmagaram
Copy link

Just adding my thoughts here as I write a library for ReScript. take is not clear - didn't realize it until I thought about it and looked at other libraries. Is it takeAtLeast, takeExactly, or takeAtMost? F# calls it truncate which is more accurate unless you plan to throw exceptions if there aren't enough items. They have a take that throws exceptions.

@benjamingr
Copy link
Contributor

@jmagaram yeah the committee isn't great at making amendments and taking feedback once a proposal is past stage 2 unless "political force" is applied and that's expensive.

From my perspective - the fact it's confusing and a (clear IMO) mistake isn't enough reason to do anything that will block this proposal since I need/want the 99% other stuff in it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants