Map does not have a type-checked "get" method

[jamesderlin]

This is the same request as #36541 but for a slightly different reason: I'd like a version of Map.operator [] that type-checks the key.

As I mentioned in #57844:

I recently found a bug where I accidentally typed someMap[someObject] instead of someMap[someObject.id]. (operator []= does use the Map's key type but operator [] uses Object.)

Arguably this wouldn't be necessary with #57844, although conceivably one might want strict type-checking without relying on lints being configured. It's also unclear what the timeline might be for implementing that.

(Alternatively, operator [] (and various other functions) could take the key type. I know that the rationale is that asking a collection of K if it contains something else isn't wrong, but it's not clear to me when it's actually the right thing to do. That is, in what circumstances is that desirable? I've seen some academic examples with questionable real-world utility, whereas the lack of typing is known to cause bugs in real code.)

[kevmoo]

I doubt we can do anything about this now – but maybe in the context of NNDB? CC @lrhn

[jamesderlin]

I suppose while I'm requesting a Map.get() method, I might as well also request that it take an optional default value to return if the requested key is not present, i.e.:

V get(K, [V defaultValue])

And then it would be similar to Python's dict.get (which is very useful and which I almost always prefer to dict[key]).

(someMap[key] ?? defaultValue is equivalent for most cases but wouldn't be the same if the Map could store null pointers.)

[eernstg]

This is a tricky problem. Map.get(K k, [V defaultvalue]) would be a strict alternative to operator [], and if we're worried about breaking existing implementations of Map we could add that as an extension method (when we get them, dart-lang/language#41):

extension StrictMap<K, V> on Map<K, V> {
  V get(K k, [V defaultvalue]) => containsKey(k) ? this[k] : defaultvalue;
}

A strict variant of other existing methods on collections (or other types) could be added in the same way. The run-time type arguments of the given map could still be subtypes of K/V, but it would give us the static checks that motivate all of this: If we think K is num then we should pass a num.

However, that would pollute the namespace, in the sense that developers who prefer the strict approach in general would need to use get everywhere rather than operator [], and similarly for remove (List.remove, Map.remove, etc) vs. strictRemove (an extension method on Lists), and so on.

Alternatively, if it's acceptable to use someMap[key] ?? defaultValue rather than someMap.get(key, defaultValue) then it would be possible to avoid changes to the shape of the parameter list, and then we could avoid the new names.

One obvious way to achieve a more strict typing would then be a lint like avoid_collection_methods_with_unrelated_types (proposed in #57844). That lint would most likely only apply to a predefined set of classes and methods like the core collections; but they are so important that this would still be quite useful.

However, we could also use the type system to enable the more strict checks. We would need to adjust the core libraries such that Map implements a new type:

abstract class StrictMap<K, V> {
  V operator [](K key);
  V remove(K key);
  bool containsValue(V value);
  bool containsKey(K key);
  ... // Declarations of remaining methods have same signature as in `Map`.
}

abstract class Map<K, V> implements StrictMap<K, V> { ... }

Note that the declarations of operator [] in Map, with no changes, are correct overrides of the declarations in StrictMap, and that there is no run-time cost.

This means that any Map can be typed as a StrictMap (it will not fail at compile time, nor at run time), and any of the methods in focus would then get the strict compile-time checks.

We could even use a separate library to rename the strict type to Map (using the upcoming generalization of typedef):

// 'strict_collections.dart'
import 'dart:core' as core;
export 'dart:core' hide Map; // Plus `List` etc.

typedef Map<K, V> = core.StrictMap<K, V>;
// Plus `StrictList` etc.

Now, with import 'dart:strict_collections', every type annotation spelled Map would now get the strict checks at compile-time.

[lrhn]

The one change I think we could possibly get away with making is to change the Map interface's [] to take the key type as argument, but keep all implementation classes as taking Object (now Object?).

It's still possible that some existing (and silly) uses will fail, or that some classes implement the interface without writing the type, and will therefore change.

On the other hand, if a map is OK to throw when upcast to something incompatible, we could drop the isValidKey of SplayTreeMap.

[ahmednfwela]

This has introduced so many problems for me.
As without static type checking, the map object is very fragile, and can break unintentionally.
I've read before that this is a design choice #28690 , but tbh it's a major flaw.
Actually it was so major, that I had to create my own (strictly typed) map mixin and classes for use within all my apps.

maybe we can change this on the next major language release (dart 3), since the language is going in the direction of null-safety anyway

[Levi-Lesches]

I imagine this would be solved by sound declaration-site variance whenever that comes.