Introduce IterableMapEntryExtension for use with Map.entries.

[jonasfj]

These utilities could often be useful when working with maps. We could also put this into a different utility package.

Example:

final myMap = {
  'foo': 42,
  'bar': -1,
  'foobar': 21,
};

// myMap without negative values
myMap.entries.whereValue((v) => v >= 0).toMap();

// myMap, but only keys that start with 'foo'
myMap.entries.whereKey((k) => k.startsWith('foo')).toMap();

---

I'm tempted to also suggest:

  Iterable<T> mapKeyValue<T>(T Function(K, V) convert) =>
      map((e) => convert(e.key, e.value));

But the name is a bit long. mapKV is lovely short, but probably too ugly.
When doing .map over Iterable<MapEntry> you generally don't want to write .map((entry) => entry.key.

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:characters	1.4.0	ready to publish	characters-v1.4.0
package:args	2.6.1-wip	WIP (no publish necessary)
package:async	2.12.0	already published at pub.dev
package:collection	1.19.1-wip	WIP (no publish necessary)
package:convert	3.1.2	already published at pub.dev
package:crypto	3.0.6	already published at pub.dev
package:fixnum	1.1.1	already published at pub.dev
package:logging	1.3.0	already published at pub.dev
package:os_detect	2.0.3-wip	WIP (no publish necessary)
package:path	1.9.1	already published at pub.dev
package:platform	3.1.6	already published at pub.dev
package:typed_data	1.4.0	already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[github-actions]

PR Health

Breaking changes ⚠️

Package	Change	Current Version	New Version	Needed Version	Looking good?
collection	Non-Breaking	1.19.1	1.19.1-wip	1.20.0 Got "1.19.1-wip" expected >= "1.20.0" (non-breaking changes)	⚠️

This check can be disabled by tagging the PR with skip-breaking-check.

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

Coverage ✔️

File	Coverage
pkgs/collection/lib/src/iterable_extensions.dart	💚 100 %

This check for test coverage is informational (issues shown here will not fail the PR).

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbols

License Headers ✔️

// Copyright (c) 2024, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

[lrhn]

I like it.
I'm not awfully happy about people working on MapEntrys in general, but this seems to be withing reason (it's not just treating them as arbitrary pairs).

[lrhn]

(Too bad where is taken, so it can't be where({bool Function(K)? key, bool Function(V)? value}))

[jonasfj]

Yes, I feel the same with .map.

But I wouldn't make where({bool Function(K)? key, bool Function(V)? value}).
I would make: where(bool Function(K, V) test), ignoring a parameter in a closure is not that bad.

Maybe, we should consider adding:

• wherePair(bool Function(K, V) test)
• mapPair<T>(T Function(K, V) toElement)

We could consider adding such extension methods to:

• Iterable<MapEntry<K, V>>, and,
• Iterable<(A, B)>.

But that seems outside the scope of this PR.

And it's entirely possible that a language feature providing pattern matching in the signature of a closure is better.

[lrhn]

Maybe whereEntry/mapEntry/anyEntry/everyEntry with an X Function(K, V) argument. (Don't say "pair", it's not — just — a pair! It's a key-and-value.)
Some of those (not whereEntry) could be extensions to Map<K,V> too. (Not saying they should, but they could.)

[lrhn]

LGTM (Rubberstamp!)

[lrhn]

Should be 1.20.0, unless 1.19.0 hasn't been released yet.
(Adds new feature ⇒ minor version increment.)