[ base ] Add unambiguous kvList
functions for sorted maps
#3392
+27
−16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Both
Data.SortedMap
andData.SortedSet
have specialisedtoList
functions.ForData.SortedSet
, I think this is a historical curious case, since its signature and semantics completely copiestoList
fromPrelude
, namely fromFoldable
, which is implemented bySortedSet
. I suggest to remove this completely in the future, but suggest now to deprecate this function in favor ofprelude
's one for backward compatibility.For
Data.SortedMap
,toList
has different meaning comparing to the one fromFoldable
, whileFoldable
is indeed implemented bySortedMap
, havingPrelude.toList
to list all the values, whileSortedMap.toList
listing all key-value pairs stored in the map. I think having two functions with the same name having different meaning is not a good thing, plus you need to specify namespace each time you usetoList
for maps (whichever you use). I suggest to introduce a new function for listing key-value pairs list, namelykvList
,and to deprecate special key-value.toList
function in favor of the new oneTo be clear: this PR is a backward-compatible change, but it adds several deprecation warnings, and I suggest the breaking change after the next release (namely, removing deprecated functions).UPD: I've striked out some outdated text after a bit of discussion and another PR being merged.
Should this change go in the CHANGELOG?
implementation, I have updated
CHANGELOG_NEXT.md
(and potentially alsoCONTRIBUTORS.md
).