non-null use after null check should not generate an error

[bsutton]

I have the following code:

https://nullsafety.dartpad.dev/cf6d285f6b0dc34e2db23e9a40ffbd01

The code does a conditional check that then nullable field is non-null.
I would expect the call to exists() to work as the I've just checked that the value is non null.

class A
{
  String? get startScriptPath => null;

  bool addToPath(String path) {
    if (startScriptPath != null) {
        if (exists(startScriptPath)) {
          print('hi');
        }
    } else {
      throw UnsupportedError(
          "The shell doesn't support a start script so we can't configure the path");
    }
    return true;
  }
  
  bool exists(String path) => true;
}

[srawlins]

Unfortunately type promotion doesn't work on fields. #104

The field could return a non-null value the first time, and null the second.

[bsutton]

So type promotion is done at complie time?

[srawlins]

That's correct. I've modified your example:

class A {
  static int calls = 0;

  String? get startScriptPath => (calls++).isEven ? 'hey' : null;

  void addToPath(String path) {
    if (startScriptPath != null) {
      if (exists(startScriptPath!)) {
        print('hi');
      }
    }
  }

  bool exists(String path) => true;
}

main() => A().addToPath('');

to show that startScriptPath can return a non-nullable, then null, producing a null-check error:

$ ~/code/dart-sdk/sdk/xcodebuild/ReleaseX64/dart-sdk/bin/dart --enable-experiment=non-nullable 1029.dart 
Unhandled exception:
Null check operator used on a null value
#0      A.addToPath (file:///Users/srawlins/code/dart-csslib/1029.dart:8:33)
#1      main (file:///Users/srawlins/code/dart-csslib/1029.dart:17:15)
#2      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:301:19)
#3      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:168:12)

[leafpetersen]

@srawlins explanation is correct. This is one of the sharper corners of the null safety release, and I'm hoping that we can provide better patterns for working with fields in the future (possibly using something inspired by swift style let guards?). On balance though, we felt that having implicit runtime checks when fields were promoted wasn't serving our users well - implicit runtime errors are generally an unpleasant surprise when they fail.

Binding the field to a local variable will allow type promotion to kick in, or you can simply use an explicit null assertion operator instead (which is what the compiler would have to do if we allowed promotion here).

class A
{
  String? get startScriptPath => null;

  bool addToPath(String path) {
    var path = startScriptPath; // Bind to a local so promotion works
    if (path != null) { 
        if (exists(path)) { // or use startScriptPath!
          print('hi');
        }
    } else {
      throw UnsupportedError(
          "The shell doesn't support a start script so we can't configure the path");
    }
    return true;
  }
  
  bool exists(String path) => true;
}