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
Add a rule to disallow mixed
types
#361
Comments
🎉 This issue has been resolved in version 3.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
The usecase for app is any function that accepts a callback and doesn't use its return value:
|
https://flow.org/en/docs/types/mixed/ Can be any primitive data type (number, string). I don't understand the example that you've shared. Shouldn't it be function callCb(cb: () => void) {
cb()
} |
It doesn't make the type weak. You can't mistakenly type number as string when using
then it will error on a callback that returns something (a promise, for example) The example is from docs: https://flow.org/en/docs/types/functions/#toc-function-type |
OK. I can see that. It doesn't make much sense to refer to it as a weak type indeed. Does it make sense to have this logic as a separate rule? |
Sure, people may want to only accept callbacks with a specific return value in their app. |
I would sincerely propose to revert this change. As @Hypnosphi pointed out correctly,
|
Agreed. Done. |
@leoselig @gajus I find this to be a matter of semantics. In Flow lingo, The bottom line is that I can make a follow-up PR to have this as a separate rule. What would be a good name? Perhaps something generic where we disallow specified values (I can't imagine why someone would want to disable other types but who knows)? |
@kangax For the same reasons that you mention I would actually vote for |
Please go ahead. Sorry for the back and forth. |
Closing as stale. |
There are cases in our app where developers use
mixed
instead of a more exact value. While there are definitely valid scenarios formixed
— e.g. on a utility/library level — they're almost never needed on an application level.It would be nice to have the rule to disallow them.
This could be another value in a
no-weak-types
or a separate rule.The text was updated successfully, but these errors were encountered: