Map filter

[Qqwy]

PR is based on this proposal.

• Implementation of Map.filter/2 and Map.reject/2.
• Implementation of the analogous Keyword.filter/2 and Keyword.reject/2
• Map.map/2
• Keyword.map/2

Questions:

• :maps.filter/2 supports a map iterator as first parameter. As we're not currently exposing map iterators through the Map module at all, my assumption is that this support is not required for Map.filter/2 etc., simplifying the code a little. Is this correct?
• :maps.filter/2's source code has some error handling/decorating. I'm not 100% sure how to convert this to Elixir code. Is this already handled by Elixir's own FunctionClause-handling where "function clauses that were tried" are printed? We might be able to remove this line from the implementation, maybe?

[josevalim]

About your questions, yes, we don’t need to support iterators and function clause errors are good enough!

[Qqwy]

I believe the implementation is finished.

Are there still places where e.g. the formatting of the documentation needs improvement?

[christhekeele]

I have just a few documentation formatting thoughts if interested, this looks great

[v0idpwn]

I think these changes could improve the documentation a bit.

While the moduledoc for Keyword specifies that functions don't guarantee ordering, I think maybe it could be good to point that in the new functions as it may be counter intuitive based on the name.

[josevalim]

💚 💙 💜 💛 ❤️

[s3cur3]

Should we document what happens when Map.map/2 produces collisions in the keys? Given that the current implementation uses :maps.from_list/2, we could just use the same verbiage as Map.new/2:

Duplicated keys are removed; the latest one prevails.

(I suppose we might conceivably not want to make any guarantees in this area and just note that collisions in keys will cause all but one instance of the key to be dropped, hinting that maybe one shouldn’t don’t do that.)

[josevalim]

@s3cur3 yes, a PR is welcome!