Request for findFirst/findLast/findSingle extension methods in SDK

[stereotype441]

Several users have run into trouble migrating code using firstWhere to null safety, specifically when using a pattern like this:

int foo(Iterable<int> list) {
  return list.firstWhere((i) => i > 42, orElse: () => null);
}

The "obvious" migration of this doesn't work:

int? foo(Iterable<int> list) {
  return list.firstWhere((i) => i > 42, orElse: () => null);
}

because the closure () => null is inferred to have the return type int (and hence returning null is not allowed).

The migration tool currently produces:

int? foo(Iterable<int?> list) {
  return list.firstWhere((i) => i! > 42, orElse: () => null);
}

which doesn't work because any caller passing an iterable of non-nullable ints to foo will now fail.

There's been some discussion of this issue at dart-lang/language#836 but that bug seems to be focused on a more general problem. There's also some discussion at #42947, but it's confusing because it looks like that bug was moved to dart-lang/language#836. I'm currently running into this trying to migrate protobufs, and it's been independently hit by Michal Terepeta and @srawlins, so I'm opening this bug to try to get the issue more attention.

The workaround I'm currently using is to write my own extension:

extension _FindFirst<E> on Iterable<E> {
  E? findFirst(bool Function(E) test) {
    for (var element in this) {
      if (test(element)) return element;
    }
    return null;
  }
}

It would be nice if this extension could be provided by the core SDK rather than requiring users to re-invent it. Particularly because then the migration tool could be programmed to automatically make use of it. If we had such an extension in the SDK, it would make sense to also include findLast and findSingle (paralleling lastWhere and singleWhere).

[davidmorgan]

Maybe tryFirstWhere, tryLastWhere, trySingleWhere to be consistent with int.tryParse?

[lrhn]

The names became firstWhereOrNull, etc., and the extension methods have landed on tip of tree in package:collection.

[stereotype441]

Was any thought given to putting these into the SDK? If they're in package:collection it's harder for the migration tool to automatically use them, since it might have to add a dependency on package:collection in order to do so.

[lrhn]

Some thought was given, but adding things to the SDK has a much higher bar than mere usefulness. Some of the added extension methods might qualify, but definitely not all of them, and we'll have to consider it more.
(Also, I'm still hoping for interface default methods, which is a better implementation choice than extension methods for a type declared in the same library).

[stereotype441]

Ok, thanks. For now I'll assume that if the migration tool wants to make use of these methods, it'll have to do so via package:collection.