Expand workarounds on 'Fixing type promotion failures' page

[parlough]

Page URL

https://dart.dev/tools/non-promotion-reasons.html

Page source

https://github.com/dart-lang/site-www/tree/main/src/tools/non-promotion-reasons.md

Describe the problem

We mostly present assigning fields to a shadowed local on this page, but I think an if-case statement is better in most cases if it matches your desired structure.

Expected fix

No response

Additional context

https://dart.dev/effective-dart/usage#consider-assigning-a-nullable-field-to-a-local-variable-to-enable-type-promotion should likely be updated as well.

[parlough]

Heya @munificent and @stereotype441 👋! In our documentation we often suggest assigning a field to a local variable to overcome type promotion failures.

With Dart 3, do you think it's fine if we expand this to suggest using if-case with a type check or non-null check for some situations? If you want or need to exit early, this won't fit all those situations currently (without dart-lang/language#2537), but in my experience this style covers most cases where promotion is needed.

So previously we'd suggest something like this:

class C {
  String? output;
  void f() {
    final output = this.output;
    if (output != null) {
      someFunctionThatExpectsNonNullString(output);
    } else {
      print('No output.');
    }
  }
}

Now we can also suggest (or even prefer):

class C {
  String? output;
  void f() {
    if (output case final output?) {
      someFunctionThatExpectsNonNullString(output);
    } else {
      print('No output.');
    }
  }
}

A related best practice question: If we do suggest a style like this, should we suggest matching the field name or suggest providing a new name for the resulting variable that relates to its promoted/tightened state?

Thanks for your thoughts! :D

[munificent]

With Dart 3, do you think it's fine if we expand this to suggest using if-case with a type check or non-null check for some situations?

Yes! A thousand times, yes.