isEmpty/isNotEmpty for Collections

[awhitford]

Similar to quiver.strings's two useful functions:

/// Returns [true] if [s] is either null or empty.
bool isEmpty(String s) => s == null || s.isEmpty;

/// Returns [true] if [s] is a not empty string.
bool isNotEmpty(String s) => s != null && s.isNotEmpty;

Shouldn't there be equivalent methods for collections? For example:

/// Returns [true] if [list] is either null or empty.
bool isListEmpty(List list) => list == null || list.isEmpty;

/// Returns [true] if [list] is a not empty.
bool isListNotEmpty(List list) => list != null && list.isNotEmpty;

[cbracken]

I agree it's a bit odd that we surface these for Strings but not for other types.

In retrospect, I'm still not entirely convinced that surfacing them was the right decision. These functions are mostly useful as quick drop-in utility functions in functional applications like stringList.where(isNotEmpty) which could equally easily be written stringList.where((x) => x != null && x.isNotEmpty). Perhaps we should have named them isNullOrEmpty though that's trickier to negate.

We did discuss something along these lines years ago and ended up on the fence. This came up on the Java side as well in Guava and was rejected, though I believe it ended up accidentally exposed in a helper class at some point and they may be stuck with it now :-) You can see Kevin Bourillion's StackOverflow reply above for rationale as to why it was rejected there.

I'm curious to hear a bit about some of the use-cases you can see for this. Iterable<Iterable<T>>s are a bit rarer than Iterable<String> in my experience.

[awhitford]

Should extension-methods be used? It's unclear on whether null values are handled.

[cbracken]

So the answer there is that for the moment you can write an extension method that works on null values, but that when Dart moves to non-null by default (NNDB), this will be disallowed in non-nullable contexts. There's some detail in the specification for extension methods.

Here's a code snippet that demos this:

extension IsNullOrEmpty on List {
  bool get isNullOrEmpty {
    return this == null || this.isEmpty;
  }
}

int main() {
  List<int> list;
  if (list.isNullOrEmpty)
    print('empty');
}

Today, this will print "empty". Post-NNBD, this will be disallowed for non-nullable contexts. During migration, it'll be a runtime error for non-nullable contexts.

[cbracken]

For what it's worth, I expect that once developers migrate to non-null by default, a lot of the need for these functions should go away -- same with Quiver's Optional type, which will be replaced by built-in language features for indicating whether nulls are permitted in a given context.