For arrow2, is it worth renaming `public fun <K...

# arrow-contributors

[phldavies]

For arrow2, is it worth renaming public fun <K, A, B> Map<K, A>.mapNotNull(transform: (Map.Entry<K, A>) -> B?): Map<K, B> to mapValuesNotNull to avoid collision with stdlib public inline fun <K, V, R : Any> Map<out K, V>.mapNotNull(transform: (Map.Entry<K, V>) -> R?): List<R>?

[Alejandro Serrano.Mena]

definitely, and right before the release of 2.0 is the right time to do it!

[phldavies]

shall I throw a quick PR together?

[Alejandro Serrano.Mena]

if you can, that would be awesome; otherwise I'll work on it during the weekend

[phldavies]

happy to - should it also be made inline while we're there? I'll include any others with similar convention (i.e. flatMap -> flatMapValues )
not sure about mapOrAccumulate though as stdlib Map<K, V>.map returns List<R> but mapOrAccumulate does the equivalent of Map<K, V>.mapValues instead. do we want/need mapOrAccumulate -> Either<Error, List<R>> and mapValuesOrAccumulate -> Either<Error, Map<K, B>>?

[Alejandro Serrano.Mena]

I would say:
• for those which do conflict right now, let's remove them right away
• for those which do not conflict but the name should be changed, add the new version and a deprecation notice with the replacement
about `inline`: if the corresponding version in the stdlib is inline, let's mark Arrow's as inline too

[phldavies]

would the deprecation cycle be aimed at introducing the mapOrAccumulate -> List varieties to match stdlib in a future release?

[Alejandro Serrano.Mena]

that should be the end goal, but there should be enough time for people to migrate to the new versions before

[phldavies]

I've raised two PRs (hopefully not a burden):
https://github.com/arrow-kt/arrow/pull/3512 - renames to avoid stdlib collision
https://github.com/arrow-kt/arrow/pull/3513 - deprecating mapOrAccumulate for map