Easier loop for maps

[HosseinYousefi]

Currently we can loop over maps via map.entries:

for (final MapEntry(:key, :value) in map.entries) {
  // ...
}

It would be nice to have either a syntax sugar or have Map<K, V> implement Iterable<(K, V)> so that we can do

for (final (key, value) in map) {
  // ...
}

[dcharkes]

cc @lrhn

[lrhn]

Not a new request.

I have some ideological oppositions to it (a map is not just a sequence of pairs!)

It's definitely not an Iterable<(K, V)>, the type of forEach is wrong. It can at most have an Iterable, like get entryPairs.

I'd then argue that if we allow that then it should be ({K key, V value}).
I'm also perfectly aware that that won't be what people want, so we might as well not do it then.

In practice, I see why you want to go through entries while naming the keys and values by what they mean in your domain, it's not like key and value are adding much information, and an Iterable of positional pairs is the least intrusive easy to do that.

So, maybe.

[FMorschel]

Just in case you aren't aware @HosseinYousefi , we have another proposal for using _ instead of MapEntry too. Not the best option but may help a bit in the meantime if it gets in the language first.

• Allow the type of an object pattern to be inferred when specified as _ #4124

[HosseinYousefi]

Not a new request.

I figured but couldn't find an issue about it.

I have some ideological oppositions to it (a map is not just a sequence of pairs!)

Iterating over a map is iterating over a sequence of pairs though.

In practice, I see why you want to go through entries while naming the keys and values by what they mean in your domain, it's not like key and value are adding much information, and an Iterable of positional pairs is the least intrusive easy to do that.

You hit the nail on the head here. Writing key and value doesn't really add much clarity. The concept of maps and dictionaries are universal enough and the order of key-first-value-second is familiar to programmers coming from other languages as well.

+1 to having a get entryPairs, it's analogous to Python's items().

[lrhn]

Since this is in the language repository, I'll take it as a request for a for loop that can loop over maps, rather than a library feature that creates an iterable of pairs.

What would that look like:

for (var k, v in map) { ... }

The map is-not-an Iterable, so there is a type hint.

That's not enough if someone wants to iterate a dynamic, so we also make the variable-or-declaration have two variables.
That is: Either the part before in is two variables separated by a comma, or it's a variable declaration declaring two variables. (If you want them to have different types, ... you're stuck, unless we allow var <declarationPattern>, <declarationPattern>. So let's do that. Then you can do any of:

var map = <int, String>{...};
for (var k, v in map) ...
for (var (int k), (String v) in map) ...
int k; String v;
for (k, v in map) ...

Or we could make it two "variable or declaration"s separated by comma .. then you can do for (int i, String j in map) ... or for (x, int j in map)..., but it's probably too confusing if for (var k, v in map) ... means v should be an existing variable.
So one declaration for two variables it is.

No records introduced at all, no need to allocate them. The semantics would be to iterate .entries and use .key and .value as the initializers for the declared variables.

(I'd be perfectly happy not allowing for/in to use an existing variable, here or in general, and require a declaration before the in. Almost nobody uses a variable there, you can always do for (var _i in ...) { i = _i; ...} to get the same effect, and it makes parsing much simpler.)

for (var k, v in map)

The types of k, v can be inferred from the statically known type parameters of map. If they are unknown, then it's dynamic, dynamic. Right?

[mmcdon20]

That's not enough if someone wants to iterate a dynamic, so we also make the variable-or-declaration have two variables. That is: Either the part before in is two variables separated by a comma, or it's a variable declaration declaring two variables. (If you want them to have different types, ... you're stuck, unless we allow var <declarationPattern>, <declarationPattern>. So let's do that. Then you can do any of:

var map = <int, String>{...};
for (var k, v in map) ...
for (var (int k), (String v) in map) ...
int k; String v;
for (k, v in map) ...
Or we could make it two "variable or declaration"s separated by comma .. then you can do for (int i, String j in map) ... or for (x, int j in map)..., but it's probably too confusing if for (var k, v in map) ... means v should be an existing variable. So one declaration for two variables it is.

Honestly I think two separate declarations would be better, meaning you would have to write:

for (var k, var v in map) ...

It's pretty common for maps to have different types for key and value, so it should be easy to express this case

for (int k, String v in map) ...
// vs
for (var (int k), (String v) in map) ...

Also imagine you have the following map.

final Map<String, ({double latitude, double longitude})> map = {
  'Chicago': (latitude: 41.878113, longitude: -87.629799),
  'London': (latitude: 51.507351, longitude: -0.127758),
  'Aarhus': (latitude: 56.162937, longitude: 10.203921),
};

With two separate declarations you could do the following

for (String city, final (:double latitude, :double longitude) in map) ...

With your proposed one declaration for both variables approach, I'm not sure how pattern matching would be supported.

final Map<String, ({double latitude, double longitude})> map = {
  'Chicago': (latitude: 41.878113, longitude: -87.629799),
  'London': (latitude: 51.507351, longitude: -0.127758),
  'Aarhus': (latitude: 56.162937, longitude: 10.203921),
};

For this map, you just write:

for (var city, coord in map) {
  print(city); // city has type "String"
  print(coord.latitude); // coord has type ({double latitude, double longitude})
  print(coord.longtitude);
}

Both types are inferred from the static type of your map.

[mmcdon20]

final Map<String, ({double latitude, double longitude})> map = {
'Chicago': (latitude: 41.878113, longitude: -87.629799),
'London': (latitude: 51.507351, longitude: -0.127758),
'Aarhus': (latitude: 56.162937, longitude: 10.203921),
};
For this map, you just write:

for (var city, coord in map) {
print(city); // city has type "String"
print(coord.latitude); // coord has type ({double latitude, double longitude})
print(coord.longtitude);
}
Both types are inferred from the static type of your map.

Of course that would work, but what if you want the option to do a pattern match instead? Having two separate declarations easily allows for both options.

// with two declarations both are fine
for (var city, var coord in map) ...
for (var city, var (:latitude, :longitude) in map) ... 

// with one declaration
for (var city, coord in map) ... // fine
// how to pattern match on coord? is it supported? what is the syntax?

  var t=[(k: 1, v:'abc'), (k:2, v:'x')];
  for (var (:k, :v) in t) {
    print('$k $v');
  }

Here, in the case of an iterable, it's supported. This means it has to be supported in a map syntax, too.

[TekExplorer]

for the record, that would be destructuring, not pattern matching

also, I would say that the least intrusive way of implementing this is to just introduce an extension like

extension MapKVIterable<K, V> on Map<K, V> {
  Iterable<(K key, V value)> get kv => entries.map((e) => (e.key, e.value));
}

and maybe include that in the SDK - naming being the only thing to consider.

for now, anyone here can just go ahead and copy-paste that to their projects.

[mmcdon20]

Here, in the case of an iterable, it's supported. This means it has to be supported in a map syntax, too.

I would hope that a map-loop syntax would support it. Note that destructuring patterns currently are not supported when you have multiple variables in a single declaration.

// with two declarations
// works
var city = 'Chicago';
var (:latitude, :longitude) = (latitude: 41.878113, longitude: -87.629799);

// with one declaration
// error
var city = 'Chicago', (:latitude, :longitude) = (latitude: 41.878113, longitude: -87.629799);

So you would either need to allow destructuring patterns in multivariable declarations or have two separate declarations.

var city = 'Chicago', (:latitude, :longitude) = (latitude: 41.878113, longitude: -87.629799);

Any idea of why this is not supported? I thought it can cause some parsing ambiguity, or require a complicated lookahead, but I failed to discover such scenarios.

[lrhn]

IIRC, the grammar isn't the problem, more the human experience.

var x = 42, (y, z) = p;

The (y, z) can get far away from the leading var, and without that var it looks exactly like a destructuring assignment.