-
Notifications
You must be signed in to change notification settings - Fork 214
Issue for discussion of super mixin type argument inference #13
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
Comments
No new discusssion (unsurprising) I'll go ahead and close this out. |
Somehow I missed this issue. There's one instance where Flutter has to ignore the |
Hmm, why does the proposal address this - it's just porting over what's already implemented for class based super-mixins? Can you point me at what the inconsistent matching classes are? |
The reason I believe that the proposal addresses the issue is in the first example given in the Inference proceeds outwards section, which seems to match Flutter's usage if you substitute I did overlook the fact that Flutter's case contains not one but two mixins, which may be where things break down. |
You're right. It's a bug that this isn't working already. |
I've updated the Dart 2.0 super mixin type inference specification to use the syntax from this proposal here. This issue is for any relevant discussion, comments, or feedback.
cc @lrhn @eernstg @munificent
The text was updated successfully, but these errors were encountered: