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
Suggestion from Performance/BlockGivenWithExplicitBlock is often slower #385
Comments
To be fair, the assumption is that with
But even then, the difference is too small to be worth in unless you enter the case where the
|
That's another point in favour of removing the linter, which tells you to replace |
ROFL, I just assumed it was advocating for So yeah, definite 👍 |
This cop flags methods where `&block` is passed to a method, which is a very common practice. There's also debate[1] as to whether specifying `&block` explicitly is better than implicitly accepting a block. [1] rubocop/rubocop-performance#385
Performance/BlockGivenWithExplicitBlock
provides bad guidance and should be removed. The benchmark which was given when it was introduced didn't test the case that a block was given, when that happensblock
is significantly slower than the other option.For Ruby 3.2+ I made
if block
faster, but prior to that the advice from this cop was always wrong. Even in 3.2+ I believe it's bad advice as there's only a very narrow usage for whichblock
is (very slightly) faster, and even in those cases it's likely a future refactor the user will accidentally introduce the slow case (ex. moving fromif block
toif block && something_else
)The text was updated successfully, but these errors were encountered: