-
Notifications
You must be signed in to change notification settings - Fork 1.7k
bad interaction: implicit downcast + inferred instantiated guarded type args #28646
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
I don't understand what you expect here. In particular:
I think this is treated the same as
It is certainly a valid optimization not to check the type arguments when casting to |
It looks like a completely plain down-cast, which shouldn't cause a warning. So, a cast from |
Ah, fair enough. I wasn't factoring in the bound. This warning is going away anyway ASAP (#28588), except possibly as a lint. We should reconsider exactly what the lint should be, but at least for now that's a linter issue and now a language issue. |
Thanks @lrhn for clarifying - that's exactly the underlying issue. My claim here is that even if we had the downcast-composite warning, we shouldn't show it in cases where the type argument is a bound. So if something is added in the linter regarding downcast-composite, this is one case that I believe should be excluded or treated differently. |
No, this is the point of the downcast composite warning. Downcast composite was added to try to point out casts that might pass on the VM/dart2js and fail on DDC. There are no types such that the cast from Siggi's point is fair, that on DDC we will prevent you from creating a |
I ran into this scenario where the implicit downcast warning comes at play, but where it doesn't feel right as a user:
This produces a warning in
B y = x
:I was expecting this case to be treated the same as
List<dynamic>
or types with no-type args: the fact that the guard is implicitly injected shouldn't add more warnings to me as a developer. In fact, I also expect the runtime cost to be the same: there should be an implicit check for B, but by construction all B's are created with a type-arg that is a subtype of A, so I don't expect extra checks for the type arguments here either./cc @leafpetersen @vsmenon
The text was updated successfully, but these errors were encountered: