Add isNullOrEmpty Getter for Nullable String Instances

[stan-at-work]

Currently, there is no direct way to check if a nullable string is either null or empty ('') without writing verbose code. Adding an isNullOrEmpty getter for nullable string instances could simplify this common check and enhance code readability.

Example Usage:

String? str;

// Instead of writing:
if (str == null || str.isEmpty) {
  // Do something
}

// With the proposed getter:
if (str.isNullOrEmpty) {
  // Do something
}

Benefits:

1. Improved readability: Reduces boilerplate code and improves clarity.
2. Consistency: Aligns with other commonly used utility methods in the Dart ecosystem.
3. Ease of use: Provides a direct and intuitive way to handle nullable strings.

Implementation Consideration:
This getter could be implemented as an extension on String? to ensure minimal impact on existing codebases.

Example Implementation:

extension NullableStringExtensions on String? {
  bool get isNullOrEmpty => this == null || this.isEmpty;
}

This is how allot of peaple do this at the moment, this could be part of the sdk for conveniance.

I believe this feature would be a valuable addition to the Dart language.

I know this is a duplicate of (#11155) but that issue had aged over 13 years...

[dart-github-bot]

Summary: User requests an isNullOrEmpty getter for nullable strings, simplifying null and empty checks. This would improve code readability and consistency with existing methods.

[julemand101]

Could you not just write?

  if (str?.isEmpty ?? true) {
    // Do something if null or empty
  }

[FMorschel]

@julemand101, I also used your suggestion on my code bases sometimes, but it is harder to read than isNullOrEmpty (point 1 in the issue description). Also, we would still have the problem of the analyzer not being able to say that after this test, str is not null too (I don't suppose this is something we have an open issue to fix @stereotype441?):

String? str = baz();
if (str?.isEmpty ?? true) {
  return;
}
if (str.isNotEmpty) { // Here currently you get a warning for unchecked_use_of_nullable_value

}

Whereas when you do:

String? str = baz();
if (str == null || str.isEmpty) {
  return;
}
if (str.isNotEmpty) { // Fine

}

---

If this is done for String?, I'd also suggest adding it for Iterable? and Map?. And then the analyzer tracking could be fixed for these cases.

Although I'd love this to be implemented I doubt it, currently. If this is done, I believe it would also make sense to add isNull only for Object? since it also needs fewer characters than == null. And feels more Darty IMO (as per points 2 and 3 of the issue description).

[julemand101]

@FMorschel Not a big fan of adding a bunch of methods that will then have specific Dart Analyzer behavior for type promotion. But if we don't do that, then the .isNullOrEmpty is annoying to use.

But yes, my suggested method does not do type promotion. In theory it could be promoted but it would require some complex logic in the analyzer.

[lrhn]

There are plenty of workarounds, including having your own extension on String? { bool get isNullOrEmpty => swith (this) { var s? => s.isEmpty, _ => true}; }.

More fundamentally, it is not a desired for the platform libraries to encourage using null and the empty string to mean the same thing.

It's a troublesome design to have two null-values that are being carried through a typed API, because it makes it very easy to forget to handle one of them in one place, and it forces the type to be nullable even if it doesn't need to.

If you are storing or producing a value, either use a non-nullable String to store it, using the empty string to represent, well "no text", and if you get a null in, store the empty string instead (?? ''), or instead use null to represent "no value" and don't special-case the empty string anywhere. Don't produce it as "no text", use null for that.

If you are getting a string from somewhere, and it might be null or it might be an empty string, but both really means that you should do nothing, convert it at the boundary.

No current plans, and no intended future plans, to add any operation like this to the platform libraries. The solution is to not have both values for any extended time.