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

Add filterKeys #866

Open
emilypi opened this issue Nov 3, 2022 · 6 comments
Open

Add filterKeys #866

emilypi opened this issue Nov 3, 2022 · 6 comments

Comments

@emilypi
Copy link
Member

emilypi commented Nov 3, 2022

Hi All,

A more general form of restrictKeys would be filterKeys, implemented thusly:

filterKeys :: (k -> Bool) -> Map k a -> Map k a 
filterKeys p = filterWithKey (const . p)

Which would allow restrictKeys to be implemented simply as

restrictKeys :: Set k -> Map k a -> Map k a 
restrictKeys s = filterKeys (`Set.member` s)

Is there an appetite for this kind of change? filterKeys is a pretty generally useful function, and restrictKeys tends to be a little too specialized too suit my needs. Since the change would arguably improve the existing functions, I think it's worth a thought.

@treeowl
Copy link
Contributor

treeowl commented Nov 3, 2022

restrictKeys exists because it can be particularly efficient.

@emilypi
Copy link
Member Author

emilypi commented Nov 3, 2022

alright, but what about the addition of filterKeys then? (assuming we leave restrictKeys alone)

@treeowl
Copy link
Contributor

treeowl commented Nov 3, 2022

I don't feel strongly about it. I guess it adds symmetry, balancing filter.

@emilypi
Copy link
Member Author

emilypi commented Nov 3, 2022

I'll go do the needful then. Additionally, I'm finding somethings are used internally, with full haddocks that would be useful to export, but are not (e.g. filterWithKeyA). Can we export those as well?

@treeowl
Copy link
Contributor

treeowl commented Nov 3, 2022

filterWithKeyA would be a good one, yeah. Maybe some more mergeA machinery too.

@emilypi
Copy link
Member Author

emilypi commented Nov 3, 2022

I'll raise separate PRs to not dirty the history

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

No branches or pull requests

3 participants