Open rrousselGit opened 2 years ago
I'm not sure that a lint rule is the appropriate way to support this, but it's definitely an interesting feature request.
I think what you're suggesting essentially amounts to
This would be prohibitively expensive as a lint because it would require re-analyzing the defining library for every function invocation in every analyzed file (in order to find the asserts that needed to be evaluated).
To make it efficient we'd probably need to store a representation of the asserts we could attempt to evaluate in the element model, just like we do for const constructors. At that point I'd suggest making is an analyzer/language
setting.
The other option would be to make it part of an off-line whole-world analysis. @srawlins
I suspect that neither of these are things we'd be able to staff any time soon, but it's definitely an interesting idea.
Describe the rule you'd like to see implemented
It is fairly common for classes/functions to include asserts such as:
Which allows:
but rejects:
The downside with doing this is, the user experience isn't perfect because it's a runtime error. I wonder if a lint rule could be implemented to showcase assertion failures statically.
Of course, we can't support every single assert failure. But simple use-cases probably could be detected
Examples
I think focusing on combinations of
x == null
/x != null
expressions could be enough as an MVPUsing the previous function:
we could statically decompose the
(a == null) == (b == null)
expression to determine that the nullability ofa
should be the same as the nullability ofb
From there, we should be able to implement:
Other cases that probably could be supported would be <> operators