Description
[Edit] We do have a rule here which says that a term like a<b, c>.toString() must be parsed as a constructor invocation when a<b, c> is a type literal, not as an instance method invocation on that type literal. But the specification does not explicitly address the case where a<b, c> is a generic function instantiation.
Old text (striking out the part which is currently not resolved, cf. dart-lang/language#1802):
Consider the test co19/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t02.dart.
In this test there is an expression a<b, c>.toString() where a is a generic function and b and c are types. The parser should parse a<b, c> as <primary><selector> where <selector> further derives <typeArguments>, because the next token is '.' (which is one of those tokens that force the preceding construct to be considered as a <typeArguments>). I believe this part works as it should.
However, that expression should then denote a toString() invocation on a function object that is obtained by explicit generic function instantiation, and there should not be any errors. The CFE reports a compile-time error Method not found.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Participants
Activity
eernstg commentedon Aug 12, 2021
The same situation seems to exist in co19/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t03.dart.
eernstg commentedon Aug 12, 2021
Same situation in co19/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t03.dart.
eernstg commentedon Aug 12, 2021
The core question here is currently being resolved at dart-lang/language#1802. Re-opening and marking as blocked.
f<int>.toString()a method invocation? dart-lang/language#1802stereotype441 commentedon Aug 23, 2021
Was just discussing this bug with @srawlins and realized that if we want
a<b, c>.toString()to be allowed (wherearefers to a generic function/method), thena<b, c>.call(...)should probably be allowed too.(@eernstg I think you've been working on test cases for this sort of thing? You might want to add some test cases for
.callif you haven't already).eernstg commentedon Aug 25, 2021
Thanks!
a<b, c>.call(...)should surely be allowed wheneverahas a function type ora.callis a constructor name, I'll include that.lrhn commentedon Aug 26, 2021
(The analyzer might want to hint that
a<b, c>(...)is a shorter version of the same thing, though).stereotype441 commentedon Aug 26, 2021
Good point. @pq or @bwilkerson, do you know whether this would be better as a lint or a hint? And would you mind taking ownership of this feature request?
eernstg commentedon Aug 26, 2021
dart-lang/language#1802 has been closed:
f<int>.toString()is a non-error term that invokestoString()on a function object, andC<int>.toString()is an error unlessC.toStringis the name of a constructor.