Skip to content
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 rules to convert .map(_ => f) to .as(f) and .map(_ => ()) to .void #41

Merged
merged 4 commits into from
Jul 18, 2022

Conversation

custommonkey
Copy link
Contributor

No description provided.

@armanbilge
Copy link
Member

Thanks for the PR! We have to be thoughtful about this one I think. The .map(_ => ()) rule is very good 👍

The .map(_ => f) to .as(f) is a bit trickier, because in the first f is lazily evaluated but in the second it is strictly evaluated. This can have implications for performance or recursion. Thus it's only safe to make this substitution if f is a val (and not a lazy val, def, or expression`).

Apologies if that's what you've already coded here (I'm not very good at reading scalafix :) in which case we should definitely add some tests cases for it

// fa.map(_ => ())
case tree @ AnonymousMap(Lit.Unit()) => Patch.lint(VoidDiagnostic(tree))
// fa.map(_ => f)
case tree @ AnonymousMap(_) => Patch.lint(AsDiagnostic(tree))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like @armanbilge says I think we have to be careful here, and without backing up out of the current tree it might be hard to tell whether the _ argument to our AnonymousMap here has already been evaluated.

It's a shame that as is not by-name for this reason.

What do you think about making this case only match on Lit subtypes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great thank's for the feed back, I'll give that a go.

Copy link
Member

@DavidGregory084 DavidGregory084 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great 💯 Thanks for the PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants