Removed Type-Defect label.
Added Type-Enhancement, Area-Editor, Triaged labels.

Added this to the M3 milestone.

We have a preference that will turn these warnings on and off globally at the moment. Doing it on a case-by-case basis as suggested here might be something we do in the future.

Set owner to @scheglov.
Removed this from the M3 milestone.
Added this to the Later milestone.

Set owner to @bwilkerson.

This comment was originally written by @a14n

I tried to use that global option, but having a lot of code dealing with js-interop, Dart editor gives me too much warnings to keep that option on. But without that, I cannot check if only declared methods are called.

I would really liked to use such a case-by-case handling. Please, don't wait too much to give us that feature. I hope "Milestone-Later" does not mean "Milestone-Never".

(in the above code snippet, I should have used "implements" instead of "extends")

Set owner to @jwren.
Removed Area-Editor label.
Added Area-Analyzer label.

dart2js is reporting these warnings too, so I think this is more of a language issue.

Added C1 label.

FWIW, the latest spec draft specifies the effect that a noSuchMethod declaration has on warnings. In particular, it does NOT sanction any wholesale suppression of warnings on uses of the type. What it does specify is that if a class implements same interface I, and a noSuchMethod declaration is present in the class (not inherited) then no warnings about missing members of I will be given.

This comment was originally written by @a14n

When I wrote this issue I was looking for a solution to control when the warnings should appear.
Sometimes I want to use noSuchMethod as a black hole that handles all the methods and there I don't want warnings but other times I want to use noSuchMethod only to provide an implementation of missing members and I'd like to get warnings on calls to undefined methods.

An alternative solution could be to

• warn on calls of undefined methods if the class doesn't directly contain NSM (but it's inherited)
• no warn if NSM is present in the class (not inherited)

What do you think ?

Gilad - I got a question about your clarification above. Will these warnings be omitted also for subclasses of the class that implements I?

To be more concrete, here is an example:

  abstract class I {
    i1();
    i2();
  }

  class A implements I {
    noSuchMethod(i) => 0; // "implements" everything in I
  }

  class B extends A {
    a1() => 1;
  }

I was expecting to have no warnings in this code, but in today's implementation we get warnings saying that B doesn't implement 'i1' and 'i2'.

Another very similar situation where we get these extra warnings is when A is an abstract class (which is what my code looks like):

  abstract class I {
    i1();
    i2();
  }

  abstract class A implements I {
    a1();
    noSuchMethod(i) => 0;
  }

  class B extends A {
    a1() => 1;
  }

eek, we hit this in JS interop package. For an example of terrible of how terrible it is, see this:

https://chromiumcodereview.appspot.com/23095010/diff/1/lib/polymer_element.dart

Set owner to @gbracha.
Removed Area-Analyzer label.
Added Area-Language label.

There is a plan to add an annotation to deal with this situation. It is is temporarily named @­Proxy, but we'll codify it in a standardized way in not too long.

The annotation is currently called "@Proxy". It will soon be in the core library. It should be specified for milestone 8 if possible.

Removed this from the Later milestone.
Added this to the M8 milestone.
Removed Priority-Medium label.
Added Priority-High label.

@Proxy takes care of class A in Siggi's example, but it does not take care of class B. I've had to deal with code where noSuchMethod is present in a base class, but has to be added to a subclass just to quite the warnings.

In js-interop there's a MagicProxy base class that implements noSuchMethod, and it's used like this:

class PersonProxy extends MagicProxy implements Person {
  // A sacrifice to the analyzer gods
  noSuchMethod(i) => super.noSuchMethod(i);
}

Otherwise warnings about not implementing Person haunt us. The particularly ugly part of this is that i\the requirement to workaround the warnings leaks to users of a library that uses nSM in a base class, you can't just deal with it in a library and ease the pain for them, they have to add the boilerplate themselves.

What Justin said.

Sorry, but @­proxy is supposed to take care of B. It is supposed to silence warnings about unimplemented methods, regardles sof noSuchMethod.

class A is taken care of because of the separate rule about noSuchMethod. As Alexandre said, that is sometimes too broad a brush, but in my view, better too few warnings than too many.

I this doesn't work as I say, we should file a bug against the analyzer.

Tentative spec for this is:

Let C be a concrete class that does not declare its own noSuchMethod() method and is not annotated with a metadata declaration of the form @­proxy, where proxy is declared in dart:core. It is a static warning if the implicit interface of C includes an instance member m of type F and C does not declare or inherit a corresponding instance member m of type F ′ such that F ′ <: F .

Added Accepted label.

I'm sorry Gilad, I wasn't specific enough. The base class has a @­proxy annotation, the subclass doesn't. Adding @­proxy is certainly nicer than adding a noSuchMethod() though.

I see. Well, you need to stick @­proxy on each class. It does not effect subclasses. I think that is reasonable behavior.

The discussion here sort of veered off from the original feature request.

noSuchMethod() can be cumbersome to work with. In general, we've found it adds a lot of pain to our ahead-of-time compilation story, and often doesn't provide as much value as users would like. For many cases, users are moving to code generation solutions instead of noSuchMethod().

Given that, we aren't planning to spend a lot of effort adding more features around noSuchMethod(), at least not any time soon.