new lint: `if_null_boolean_conversions` (use ?? to convert null to a boolean value.)

[pq]

I'm sure someone can come up with a better name but the rationale is in dart-archive/linter#2458 (comment). The advice from effective Dart is

DO use ?? to convert null to a boolean value.

See: https://dart.dev/guides/language/effective-dart/usage#do-use--to-convert-null-to-a-boolean-value

Cheers @a14n for the suggestion 🍻 .

[bwilkerson]

Some variations on the style guide entry (to make searches easier):

• convert_null_to_bool
• convert_null_to_bool_with_if_null
• use_if_null_to_convert_null_to_bool

[a14n]

After trying such a lint on flutter I found a interesting case. The user has to be careful about precedence because == takes precedence on || but || takes precedence on ?? so the following code should be converted with parents (not sure it reads better):

-    final bool isDateInvalid = widget.minimumDate?.isAfter(selected) == true
-                            || widget.maximumDate?.isBefore(selected) == true;
+    final bool isDateInvalid = (widget.minimumDate?.isAfter(selected) ?? false)
+                            || (widget.maximumDate?.isBefore(selected) ?? false);

TBH I find a?.b == true easier to read/understand rather than a?.b ?? false (but that's not the place for discussion about effective Dart ;) )

[pq]

/fyi @munificent

[bwilkerson]

I find a?.b == true easier to read/understand rather than a?.b ?? false ...

I actually find the opposite to be true.

1. The recommended form makes the default value explicit; the first form forces me to think about the comparison logic to know whether the default is the value on the right or the inverse (depending on whether == or != is used for comparison and whether the value is compared against true or false).

2. The recommended form is more consistent with other places where we specify a default value, such as counts[value] ?? 0.

[a14n]

but you can find a?.b == false that can also be considered inconsitent if you change a?.b == true to a?.b ?? false

[parlough]

I do think the recommended form is nice in that it's more explicit, but from that angle I prefer simply:

return a != null && a.b;

It's not much longer, perhaps more explicit in its intentions, and I believe there are situations where this style has improved type inference currently.

[a14n]

With a?.long.expression.chain.that.may.be.really.long instead of a, the form a != null && a.b is not an option ;)

[munificent]

This lint is great! However, there is a caveat now with null safety and type promotion. Sometimes, it's better to use an explicit != null check because ?. doesn't type promote. You can see the updated guideline here with some more context here.

Ideally, this lint wouldn't fire if changing the code to ?? ends up interfering with type promotion.