New Map ctor: Map.convert (or optional args to .from)

[kevmoo]

See https://code.google.com/p/dart/issues/detail?id=11750

Map.convert(Map other, {K keySelector(key, value), V valueSelector(key, value)})

The default keySelector selects the keys. The default valueSelector selects the values.
So the default behavior is the same as Map.from(map)

I might like this more than the suggestion in 11750, if it was adopted by the other Map subclasses. Then one gets the flexibility of choosing which subclass to use with the same functionality.

[iposva-google]

Added Area-Library, Triaged labels.

[lrhn]

We could make keySelector and valueSelector optional arguments on Map.from.

---

Removed Type-Defect label.
Added Type-Enhancement label.

[kevmoo]

That's good, too.

[floitschG]

Why not just use new Map.fromIterables(map.keys.map(keySelector), map.values.map(valueSelector)) or
Map.fromIterable(map.keys, (key) => valueSelector(map[key])); ?

[kevmoo]

Bumping this again.

.fromIterables requires 2 iterations through the source map. Depending on the implementation, this could be pretty expensive.

[lrhn]

A pairs/entries iterable on Map looks like it could be the most general solution.
It will cost an extra allocation per entry, but it will most likely be short-lived.

[floitschG]

Also see #9590 which asks for the same thing as instance-method.

[rakudrama]

I think there are nicer solutions:

• A MapIterator that allows access to currentKey and currentValue without allocating Entry objects. Perhaps this could subclass Iterator (i.e. with accessors current and currentValue).
• Rank 2 iterables is a previous attempt to advocate for something more usable in this space.
• Extending for-in with syntax to bind keys and values. I have seen several cases of awkward code using Map.forEach on scanning loops that should have an early exit or return.

[kevmoo]

I'm super happy with fromEntries now...