Skip to content
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

Type propagation should infer both upper and lower bounds for type parameters of literal lists and maps #18269

Closed
stereotype441 opened this issue Apr 16, 2014 · 6 comments
Labels
analyzer-ux area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug

Comments

@stereotype441
Copy link
Member

In some circumstances it makes sense for type propagation to infer the most specific possible type for the elements of a literal list or map. For example, when offering completions for:

  main() {
    var numbers = [1, 1, 2, 3, 5];
    numbers[0].

it makes sense to infer that numbers has type List<int>, so that we can offer completions for int.

However, in others, it makes sense for type propagation to infer the least specific possible type. For example, when generating hints for:

  class A {}
  class B extends A {}

  void main() {
    List<A> as = [];
    [new B()].addAll(as);
  }

we should infer that the type of [new B()] is List<A>, so that it is compatible with the call to addAll() (see issue #17934).

I suspect that we can address this issue by inferring both a lower bound and an upper bound for each type parameter, using a Hindley–Milner style type inference algorithm. In the example above, upon encountering "List <A> as = []" we would infer a type of List<T1> where T1 <= A. Upon encountering "[new B()]", we would [new B()]", we would infer a type of List<T2> where B <= T2 <= dynamic. Then, when processing ".addAll(as)" we would unify types T1 and T2 and deduce that B <= T2 = T1 <= A.

@bwilkerson
Copy link
Member

Added this to the 1.5 milestone.
Removed Priority-Unassigned label.
Added Priority-Medium, Analyzer-UX labels.

@bwilkerson
Copy link
Member

Removed this from the 1.5 milestone.
Added this to the Later milestone.

@kasperl
Copy link

kasperl commented Jul 10, 2014

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

@kasperl
Copy link

kasperl commented Aug 4, 2014

Removed Oldschool-Milestone-Later label.

@stereotype441 stereotype441 added Type-Enhancement area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. analyzer-ux labels Aug 4, 2014
@kevmoo kevmoo added P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug and removed triaged labels Mar 1, 2016
@bwilkerson
Copy link
Member

@stereotype441 Should we close this issue?

@srawlins
Copy link
Member

I'll close this for now. Re-open if this is still a problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyzer-ux area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

5 participants