Skip to content

Analyzer did not infer the correct type after checking type of the class member #37604

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
RaymondChao opened this issue Jul 23, 2019 · 1 comment
Labels
closed-as-intended Closed as the reported issue is expected behavior

Comments

@RaymondChao
Copy link

In below example, the Dart analyzer did not show any errors:

class Bowl {
  dynamic animal;

  Bowl() {
    animal = Fish();
  }

  void shake() {
    if (animal is Fish) {
      animal.jump();
    }
  }
}

class Fish {
  swim() {
    print('swim');
  }
}

void main() {
  Bowl().shake();
}
@eernstg eernstg added the closed-as-intended Closed as the reported issue is expected behavior label Jul 23, 2019
@eernstg
Copy link
Member

eernstg commented Jul 23, 2019

The method jump can be invoked on animal because the type of animal is dynamic.

You probably expected animal is Fish to promote animal such that its type would be Fish in the body of the if statement, but that doesn't happen because instance variables are never promoted (here are a couple of related issues: #34480, #25565).

We expect promotion to be revised in several ways (e.g., we may promote after if (animal is! Fish) return; which means that the control flow analysis is made stronger). But promotion of mutable instance variables is not so likely to happen, because any invocation of a method or function may allow such instance variables to be mutated and hence invalidate the type that we just tested for.

It would be useful to have the property that all promotions are associated with explicit syntactic constructs, which could mean that anything like if (animal is Fish) ... would be flagged (with a lint, hint, or something like that) because it does not promote animal. But that would be a breaking change and there could be many situations in existing code where such diagnostics would just be annoying noise. So there is no easy way to detect and report the situations where promotion was intended and expected, but didn't happen.

I'll close this issue with 'working as intended'.

@eernstg eernstg closed this as completed Jul 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-as-intended Closed as the reported issue is expected behavior
Projects
None yet
Development

No branches or pull requests

2 participants