-
Notifications
You must be signed in to change notification settings - Fork 170
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
Analyzer doesn't warn for comparison of unrelated type extension values #4912
Comments
Should it? If the representation types are related, and An extension type which implements its representation type is as close as we can come to an "open" extension type, which makes no secret of its representation type. I'd be fine with not having any warning about comparing two strings with different sets of additional methods. |
Agreeing with @lrhn that it may be fine to omit the diagnostic for extension types that implement non-extension types that wouldn't cause a diagnostic, it does make sense to emit a diagnostic for other unrelated extension types: extension type Inch(double value) {...}
extension type Centimeter(double value) {...}
void main() {
print(Inch(1) == Centimeter(1)); // 'true', deceptively.
} |
I have to say it's pretty confusing. I have two wrapper types that I'd like to behave as Strings but with added type safety:
While I can perhaps understand why it would make sense engineering-wise (knowing what a type extension does) for these to be comparable without a warning, it seems awkward and error prone from a developer experience point-of-view.
|
I proposed that we should use a keyword (e.g., So we have to rely on the softer property that an "open" extension type implements a non-extension type This basically means that if you have That's also the reason why you can do
They will not be considered the same type. In particular, an However, at this point you've convinced me that we should use a stricter approach: unrelated_type_equality_checks should simply use the same rule for extension types that it is already documented to use for all other types:
So, based on the fact that This means that we will keep the "level of incompatibility" for assignments and for |
That's great! Thanks for listening 🙂 |
Thanks! (It's up to the analyzer team to make a decision, though.) |
This one makes me feel squirmy. What we'll be saying with this proposed change is, "You should not compare these two things. Oh, don't be fooled, they could totally be equal to each other. But you still shouldn't compare them." I think that is precisely the request. I'm not against it; I just want to phrase it this way. I'll note that "unrelatedness" is a shared computation between
|
I think the relevant question is the following: Is it going to be helpful to anyone if we insist that an Can we come up with a situation where unrelated extension types conceptually ought to be comparable, that is, a situation where we really want |
The below code doesn't cause the analyzer to emit any warning for comparison of unrelated types:
Flutter doctor:
The text was updated successfully, but these errors were encountered: