Skip to content

Strong mode implicit generic instantiations should be limited to known targets #28162

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
leafpetersen opened this issue Dec 20, 2016 · 3 comments
Assignees
Labels
dart-model-analyzer-spec Issues with the analyzer's implementation of the language spec legacy-area-analyzer Use area-devexp instead. P2 A bug or feature request we're likely to work on type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Milestone

Comments

@leafpetersen
Copy link
Member

leafpetersen commented Dec 20, 2016

[Update: 2018.06.05] The new CFE implements this correctly, analyzer handles all but the generic function typed variable case correctly.

Per language team decision, we will not support implicit instantiation (via inference) of arbitrary function expressions, but instead only for statically resolvable tearoffs. That is, a reference to a generic function declaration or a closurization of a generic method can be simultaneously instantiated at the tearoff point, but a general function expression cannot be.

Examples:

void take(int f(int x)) {}

T foo<T>(T x) {}

class A {
  T bar<T>(T x) {}
}

T Function<T>(T x) returnFoo() => foo;

void test() {
  T baz<T>(T x) {};
  take(foo); // instantiated to int
  take((foo)); // instantiated to int
  take(new A().bar); // instantiated to int
  take (baz); // instantiated to int
  take(<T>(T x) => x); // Error, not instantiated
  var g = foo;
  take(g); // Error, not instantiated
  take(returnFoo()); // Error not instantiated
}

[Updated 2017.06.02 with bug fix]

@mit-mit mit-mit added this to the 1.22 milestone Dec 21, 2016
@bwilkerson bwilkerson added P2 A bug or feature request we're likely to work on type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) labels Jan 2, 2017
@kevmoo
Copy link
Member

kevmoo commented Jan 13, 2017

@leafpetersen is this critical for 1.22?

@leafpetersen
Copy link
Member Author

No, doesn't need to be 1.22 at all. Very small change in inference, no impact on non strong mode code.

@kevmoo kevmoo modified the milestones: 1.50, 1.22 Jan 13, 2017
@dgrove dgrove modified the milestones: 1.50, 1.23 Feb 14, 2017
@leafpetersen leafpetersen removed this from the 1.23 milestone Mar 9, 2017
@bwilkerson bwilkerson added this to the Dart2.1 milestone Sep 2, 2018
@bwilkerson bwilkerson modified the milestones: Dart2.1, PostDart2.1 Sep 4, 2018
@aadilmaan aadilmaan modified the milestones: Future, D25 Release Jun 4, 2019
@srawlins srawlins added the dart-model-analyzer-spec Issues with the analyzer's implementation of the language spec label Jun 17, 2020
@srawlins
Copy link
Member

This feature has been reversed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dart-model-analyzer-spec Issues with the analyzer's implementation of the language spec legacy-area-analyzer Use area-devexp instead. P2 A bug or feature request we're likely to work on type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

8 participants