Dart treats a final nullable property as nullable even after checking that the property is not null

[lsalazarm99]

Considering this code:

void main() {
  Person person = new Person(
    name: "Leonardo",
  );
  
  if (person.jobTitle != null) {
    showInConsole(person.jobTitle); // Error: The argument type 'String?' can't be assigned to the parameter type 'String'
  }
}

class Person {
    final String name;
    final String? jobTitle;

    const Person({required this.name, this.jobTitle});
}

void showInConsole(String text) {
  print(text);
}

In the error line, person.jobTitle will not be null as it was checked for that before, but the analyzer keeps it with its original signature. Because of that, it is not usable inside the showInConsole function.

Some workarounds?

• Using a local variable for the property. In this case, I'm not sure if the analyzer keeps the local variable with its original signature after the null check, but it doesn't show an error anymore.

String? jobTitle= person.jobTitle;

if (jobTitle != null) {
    showInConsole(jobTitle); // no errors
}

• Using the ! operator. But I'm not sure about this. Coming from TypeScript, this is a bad practice because if I remove the null check for some reason, it won't show the error and it will be throwing a runtime error.

if (person.jobTitle != null) {
    showInConsole(person.jobTitle!); // no errors
}

The first workaround is the safest way, I think. But what if I change the type of cardBrand in the future? I would need to change it in every location I check for the property to not be null. Also, it could be annoying to create a local variable for every property you need to check.

If the analyzer can follow the flow of the first workaround for a local variable so it knows it's not null, shouldn't it do the same for the property of a local variable?

[lsalazarm99]

@tatumizer In that situation where you are getting the value from a function, I can understand that even if you check the return value to not be null, it doesn't mean the value won't be null when you run the function again (unless it is a pure function, but that might be more complex).

But what I am doing is not running a function so a non-ready-value. I am accessing a class property that is even marked as final so if I already checked for that property to not be null, it's impossible for that property to be null.

Also, I know person could be resigned so jobTitle could be null even after check. But if I mark person as final, the error is still present.

If I am checking the final property of a final variable to not be null, shouldn't it be enough for the analyzer to know it won't be null never?

[lsalazarm99]

I agree with you that, in your example, the error should be shown. As you said, jobTitle is overridden by a getter (so a function). And as a function, its return value might not be the same after every execution. That's why it should show an error.

But in my example, jobTitle is not a function. Is a final property. Yes, it can be overridden by another class, but I'm not using that other class. I'm using the class Person and its already final declared jobTitle. If I try to update the property or the final variable person, the analyzer won't let me because it will show an error telling me that it's not possible to set again those values.

void main() {
  final Person person = new Person(name: "Leonardo");
  
  person = new Person(name: "Eduardo"); // Error: The final variable 'person' can only be set once
  person.jobTitle = "Developer"; // Error: 'jobTitle' can't be used as a setter because it's final
  
  if (person.jobTitle != null) {
    // Since person can not be reassigned either its property jobTitle,
    // and I have already checked that person.jobTitle is not null,
    // it is safe to say that person.jobTitle won't be null never.

    showInConsole(person.jobTitle); // Error: The argument type 'String?' can't be assigned to the parameter type 'String'
  }
}

class Person {
    final String name;
    final String? jobTitle;

    const Person({required this.name, this.jobTitle});
}

void showInConsole(String text) {
  print(text);
}

Since those values can not be reassigned and the analyzer knows it, shouldn't it also know that if I'm checking for those values to not be null, those values won't be null inside the if statement?

In case those values could be reassigned, how could you reassign this so it is reasonable to show an error?

final Person person = new Person(name: "Leonardo");

[lsalazarm99]

Well, you could argue that the compiler can see the declaration Person person = new Person(name: "Leonardo"); and thus, the Person is just a basic Person, in which the jobTitle is final.

In this situation, checking for the property to not be null should be enough since, as you said, the compiler can see the declarations.

But in the next version, you can modify it: Person person = giveMeAPerson()); And now compiler cannot assume anything about the real type of Person and hence about the finality of jobTitle.

In this situation, where the code has changed, since the compiler doesn't know because I'm using a function, it is reasonable to show the null-safety error.

Maybe there is something I'm still not getting, but I'm not talking about the second situation. I'm talking about the first situation, which is a different one because the compiler can see that the property won't be null.

[srawlins]

but I'm not using that other class

A small change in your program will break your program in ways you don't expect (the reason for the breakage is subtle).

I think this is an important consideration. I think the language team has looked at the various cases in which a developer says "but I know the field isn't overridden," such as private fields (#1167), @sealed classes. Even in your case, the Person() constructor could be a factory constructor which returns a PersonToBeDemoted. Right now there are limited controls of variance in Dart; any time the static type of an object is Person, this means that the runtime type could be any subtype of Person.

One consolation is that the runtime behavior might take knowledge into consideration with optimizations. Looking at:

if (person.jobTitle != null) {
    showInConsole(person.jobTitle!);
  }

If the compiler has optimizations (based on visibility, exact type, etc), then it may not need to execute that ! null check. But for the sanity of the language, the ! must remain because of specification of the static types.

[srawlins]

Duplicate of #1330

[Cat-sushi]

label:field-promotion is also related to this issue.

[Cat-sushi]

If fields are promoted in some case and aren't promoted in other case depending on global analysis, it is also confusing very much.

[lrhn]

@tatumizer wrote:

Dart AFAIK always compiles the program from the sources - there's no partial compilation, precompiled libraries, etc.

That is not correct. Dart does, at least for some compilers, have modular compilation. I believe the development compiler (dartdevc) is one. Among other things, that's what enables hot reload. If you had to wait for the entire program to be compiled, you'd at most have luke-warm reload. 😁

Also, a package is a program part which is also compiled and run (for testing) independently of the program(s) it's part of.
If having a subclass changes the behavior of the superclass, then a superclass method getting field promotion due to not having a subclass, would break in a program where a subclass is added.

It is vitally important to Dart's approach to object oriented programming (and ditto for most other languages with subclasses) that you can write a superclass without knowing its subclasses ahead of time. If you can write code in an instance method, which is then invalidated by a subclass, then you can't really use that feature safely anywhere. (Basically what @Cat-sushi said, if promotion inside a method depends on a global analysis of the entire final program, then it's incredibly fragile.)

Using global information for optimization is great, it enables more possible optimizations.
Using global information to change semantics is not, it makes the semantics unpredictable and therefore unusable.

If you could declare that a class cannot have subclasses (or not subclasses outside of the declaring package), then you don't need global information (or seen differently, you have global information because the local declaration ensures global cooperation. And that only works with actual language features, not annotations that might or might not be checked).

[lrhn]

It's about being able to see where things can fail. If you see person.jobTitle!, then you know that a null check occurs there. You can look to the surrounding code for hints to why the code feels safe to assume that the value won't be null.
And the author might consider whether there are better ways to do the same thing, one where you only make one type check.
That's why visibility is good, it allows you to notice things. It doesn't prevent you from doing something stupid if you really want to, but then again, nothing ever really does.

A ! is still a run-time cast. It's a cast from T? to T (where the type system can usually figure out which non-nullable type you mean). It's still able to fail at run-time, just like as T would. We're definitely not trying to encourage anybody to spread ! casts around their code. I hope that future code will more often be written in a way where it's not necessary to use !, or where it's used as sparingly as as should be now.

Existing code didn't have that possibility, and migrating existing code might (as the path of least rewrite) require adding ! in places where the current code would also fail (possibly later) if the value is actually null.

[lsalazarm99]

Clearly you guys know more than me in this subject, and that's probably why I still can't understand something that seems obvious for me and probably many of the people with this issue.

final Person person = Person(name: "Leonardo");

In this sentence, I'm saying that the type of person is Person, and yes, it could be any subtype of Person. But then, through using Person() I'm saying that actually is not a subtype, but is just a Person.

So now the analyzer have all the information it needs (the exact type that the variable is and the information about that type).

Given that, shouldn't it know that if I'm checking for person.jobTitle to not be null, it won't be null?

Sure, in a future the code can change. If instead of using Person() I use Developer(), the analyser should then treat that variable as that subtype, but nothing else. If Developer overrides jobTitle with a getter, it will start complaining where you use your person variable. If it doesn't override it, it won't complain because it's still a simple nullable property that I already checked to not be null.

I can even change the jobTitle of Person and making it a getter and sure, I will understand it would need some refactor in my code because that's usually what it means to change the structure of a class.

But right know, in that line of code I wrote at the beginning (and the structure of Person), the analyzer have enough information to know that if I'm checking for jobTitle to not be null, it won't be null.

[lsalazarm99]

@tatumizer Many thanks, finally I understand what's happening and why is the shown error "valid".

[lrhn]

I generally create local variables if I have to check-and-use a nullable instance variable. That is a way to avoid the !, it's just a tad verbose.
I would very much like to have a feature which can check-and-bind in one operation, perhaps something like if (x is Foo foo) or if (x is! Null foo) which checks the value and binds it to a new variable only if it's not null. That allows me to introduce a new variable, check the value and promote the value along the successful check, which is the same thing I'm already doing, just with less verbosity.

I don't think we'll ever see sound promotion of virtual getters. We might be able to see it on non-virtual getters, but even there I'm somewhat against it because it would probably not work on getters, only fields, and that breaks the field/getter symmetry and locks classes into their current implementation.

Interfaces are promises about API and behavior, but only the API can really be checked by a computer. If we know that x.foo is a getter returning an int, that is all we know. We do not know that it's the same value each time you read it.
Dart has chosen to have fields and getters/setters be symmetric, so you can replace one with the other. That is, being a field is an implementation detail, not an API property. C# did something different, where they have getters and setters in the API, which are just methods called in special ways, but fields are completely different and (IIRC) not even virtual - so you have to write your getter/setter pair to access the field in a virtual way (like Java's getFoo/setFoo, just with nicer call syntax).
If we don't want to break that field/getter symmetry in Dart (and we still don't), we can't start assuming that even a final static field is promotable, because it would make it a breaking change to refactor that field into a getter.

Our problems here are largely self-inflicted. Because we can't look below the API to see that something really doesn't change (because either it's not guaranteed to be true because the getter is virtual, or because the promotion we'd do would then be fragile and depend on the getter staying a field), we can't promote anything except local variables.
I do not believe that can change without dropping some very fundamental assumptions in the Dart design.

So, I want to focus on providing a different and better way to get a promoted variable from any existing value, rather than focusing on linking separate reads of a fundamentally unknowable getter.