Analyzer fails to respect certain "is" checks

[nex3]

Consider the following code:

    import "dart:typed_data";

    void doIt(List list) {
      if (list is TypedData) print(list.buffer);
    }

Running the analyzer on this produces the following error:

    [warning] There is no such getter 'buffer' in 'List'

despite the fact that "list" must be an instance of TypedData in the "if" block, and TypedData defines a "buffer" getter.

[kevmoo]

Related to (duplicate of?) https://code.google.com/p/dart/issues/detail?id=6397

[bwilkerson]

Added this to the M6 milestone.
Removed Priority-Unassigned label.
Added Priority-Medium label.

[bwilkerson]

Unfortunately, it has been decided that dartanalyzer and the editor cannot use type inference to eliminate errors and warnings. The only way to get rid of this error would be to write

  print((list as TypedData).buffer);

even though the cast seems redundant.

---

Set owner to @bwilkerson.
Added WontFix label.

[nex3]

I thought this had been changed in the spec, but it still seems not to work. Was I misinformed?

[bwilkerson]

I thought this had been changed in the spec, but it still seems not to work. Was I misinformed?

It was changed in the specification, but only for a very limited set of cases. The specification reads:

    Let v be a local variable or a formal parameter. An is-expression of the form v is T shows
    that v has type T iff T is a more specific than the type S of the expression v and both
    T != dynamic and S != dynamic.

So in this case, the parameter 'list' would be shown to have type 'TypedData' iff 'TypedData' is more specific than 'List'. Unfortunately, there is no relationship between 'TypedData' and 'List', so we cannot use that information for the purposes of suppressing warnings. If 'TypedData' implemented 'List', then this would work the way you expect.

[Hixie]

I don't understand this limitation. If you enter a code block that's gated by an if (foo is Bar), then it makes no sense to me that the analyzer wouldn't assume that isn't that block, foo is a Bar, irrespective of any other types that it might think foo is as well.

[bwilkerson]

Consider the following code:

abstract class A {
  void mA();
}

abstract class B {
  void mB();
}

void f(A p) {
  if (p is B) {
    p.mA();
    p.mB();
  }
}

In the absence of intersection types you can choose one of two "wrong" semantics. Within the body of the if, either p has type A or p has type B. Either way you end up with a spurious error message.

The original authors chose one of the two options, but both are bad. I'm not sure which would result if fewer spurious error messages in practice. Feel free to re-open this case if you want the language team to consider changing this behavior.

[Hixie]

I think the analyzer should assume that in that block, p is both A and B.

[Hixie]

(i don't have the access to reopen bugs in the dart sdk repo :-) )

[bwilkerson]

We tried adding union types behind the scenes awhile back and it turned out to be so confusing to users that we ended up backing all that out. I'm concerned that intersection types would be the same. In any case, this behavior is currently part of the specification, so I'm turning this into a language issue.

[lrhn]

Looks like a variant of an "improve type promotion" request (#25565)