-
Notifications
You must be signed in to change notification settings - Fork 35
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 rule enforcing explicit return #467
Comments
Could you show a case where implicit return would be a footgun? |
@straight-shoota We had an unnoticed buggy method that was effectively def something : Bool
if cond
# .. extra evaluation ..
true
end
false
end which was unlikely to ever be written in the first place if implicit returns didn't exist. You would never just write naked The subjective benefit of implicit return's brevity is outweighed by
So we are more than fine with enforcing it. |
I suppose this requires semantic analysis for being any good. Without a semantic pass you dont know which code paths are So at this point |
@z64 Regarding the consistency argument: There are far more significant differences between the semantics of different programming languages than implicit returns - which is actually a very obvious one. Anyway I believe for that example it might be helpful to recognize a "naked |
Without semantic analysis that's going to be pretty useless, as mentioned already by @straight-shoota. |
While implicit return is nice, sometimes it can cause unintended effects / footguns. Would it be possible to add a (disabled by default) rule that's the exact opposite of Style/RedundantReturn, encouraging the use of explicit returns?
The text was updated successfully, but these errors were encountered: