Null safety feedback: final field check for null does not convince the compiler field is not null

[renatoathaydes]

This fails to compile on line 18, but it should work because the field is final so the null check ensures the field can't be null.

class Hello {
    final String? stackTraceString;
  
    Hello({this.stackTraceString});

    StackTrace? get stacktrace =>
      stackTraceString != null ? StackTrace.fromString(stackTraceString) : null;

}

DartPad Link.

Dart version:

Dart SDK version: 2.11.0-213.5.beta (beta) (Thu Oct 29 11:45:16 2020 +0100) on "macos_x64"

[mraleph]

That's because final field is not necessarily field at all:

class Hello {
    final String? stackTraceString;
  
    Hello({this.stackTraceString});

    StackTrace? get stacktrace =>
      stackTraceString != null ? StackTrace.fromString(stackTraceString) : null;

}

class MyHello extends Hello {
    @override
	String? get stackTraceString => random.nextBool() ? null : "something";
}

Meaning that you can't soundly promote fields based on a comparison. See dart-lang/language#104 and other linked issues for discussion.

[renatoathaydes]

Why even have final if the language does not enforce anything one would expect from final?

[mraleph]

Why even have final if the language does not enforce anything one would expect from final?

final means you can't write into it. And indeed you can't.

Remember Dart 1 was a very different language from Dart 2. It had type annotations that did not enforce anything - but existed to communicate intent. Some of the design decisions come from that era and unfortunately we will have to live with them for some time.