Can we implement String.IsNullOrEmpty and String.IsNullOrWhiteSpace as part of the core libraries

[DartBot]

This issue was originally filed by ir...@google.com

---

These two methods are very commonly used in almost every application. Is it possible to make them as part of the core libraries to avoid having to create utility classes for very basic functionality.

[kasperl]

Added Area-Library, Triaged labels.

[lrhn]

The methods cannot be instance methods of String, because then they won't be called if you try to call it on null.
They could be static methods on String, but then there is no great saving from using your own library methods.

I don't particularly like the functions. I don't find it more readable than checking explicitly, and depending on variable names, it's not even shorter.

 s == null || s == ""
vs
 String.isNullOrEmpty(s)

 s == null || s.trim() == ""
vs
 String.isNullOrWhiteSpace(s)

(but that's admittedly a too short variable name in most cases).

I also think the white-space one is too specialized to really make sense as a library function.

---

Removed Type-Defect label.
Added Type-Enhancement label.

[floitschG]

I agree with Lasse.

---

Added NotPlanned label.

[DartBot]

This comment was originally written by @jonaskello

---

For anyone else arriving at this issue from searching it might be of interest to know that the quiver package has these methods:

quiver.strings
isBlank checks if a string is null, empty or made of whitespace characters.
isEmpty checks if a string is null or empty.

[xster]

I'd argue there's still more cognitive load on the explicit expression vs a static String.isNullOrEmpty. There's a single mode of runtime failure for the static method (incorrect ! in front) whereas the full expression can fail on the incorrect negation, incorrect == vs != times 2, incorrect de morgan application.

It doesn't take much thinking but since it's so frequently used, any amount of infallible muscle memory is helpful.

[lrhn]

I think the quiver solution is better than a static member on the String class because it doesn't require the String. prefix. Not being prefixed means that it should not be in dart:core, it should be something that you opt-in to including it in your top-level name space. A package is precisely that.

[xster]

(looks up quiver)
SG

[rrifafauzikomara]

You can create your extension to check the string is null or empty and the string is null or have space.

Extension:

extension StringExtensions on String {
  bool isNullOrEmpty() => this == null || isEmpty;

  bool isNullOrWhiteSpace() => this == null || contains(' ');
}

Implementation:

  String data  = null;
//   String data  = '';
  if (data.isNullOrEmpty()) {
    print('Empty / Null');
  } else if(data.isNullOrWhiteSpace()) {
    print('Contains Spaces');
  } else {
    print('Not Empty / Not Null');
}

[jamotaylor]

@lrhn what about nested properties?

In this case extension methods (as mentioned by @rrifafauzikomara) do not resolve the issue - any null higher up the chain will throw an error:

if (data?.property?.stringProp.isNullOrEmpty()) {
  print('this will error if data or data.property is null');
}

Using data?.property?.stringProp.isEmpty ?? true seems vague to me and as @xster noted, increases "cognitive load", whereas String.IsNullOrEmpty(data?.property?.stringProp) seems most easily readable - and typeable :)

[lrhn]

I don't think static methods is the way most people are taking Dart code. With extension members, it's usually better to use those.
In this case you can do: if ((data?.property?.stringProp).isNullOrEmpty) .... It requires parentheses, but that's probably a good thing since it highlights that the nullability it checks for comes from the entire preceding expression, not just from stringProp.

[guuguo]

The methods cannot be instance methods of String, because then they won't be called if you try to call it on null. They could be static methods on String, but then there is no great saving from using your own library methods.

I don't particularly like the functions. I don't find it more readable than checking explicitly, and depending on variable names, it's not even shorter.

 s == null || s == "" vs  String.isNullOrEmpty(s)

 s == null || s.trim() == "" vs  String.isNullOrWhiteSpace(s)

(but that's admittedly a too short variable name in most cases).

I also think the white-space one is too specialized to really make sense as a library function.

Removed Type-Defect label. Added Type-Enhancement label.

but like this?
globalLogic.adConfig?.adFlowId.isNullOrEmpty
vs
globalLogic.adConfig?.adFlowId?.isNotEmpty != true

[guuguo]

我实现了拓展方法，但是还是不能使用：

extension NullSafe on String?{
  String get safe{
    return this??"";
  }
  bool  get isNullOrEmpty=>  this?.isNotEmpty!=true;
}