-
-
Notifications
You must be signed in to change notification settings - Fork 206
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
Fix implicit syntax collisions #629
Fix implicit syntax collisions #629
Conversation
LGTM @vladimirkl thanks for the PR! Do you know if it applies to any other macros? or other syntax classes? |
btw does this change only apply to cats branch? if not could you update the PR toward master, we will cherry pick it back to cats on the next realease. |
I think that issue applies to every syntax class that subject as public field. Btw they are defined inconsistently - some are |
ac61eb7
to
f9b5c8c
Compare
Thanks @vladimirkl ! |
@julien-truffaut should I make a PR for cats branch with cherry pick? |
it would be great if you have time |
This PR fixes a collision when we use something like scala-newtype and have
import monocle.macros.syntax.lens._
in scope. A cause of collision isval value: A
inGenApplyLensOps
so it conflicts with any.value
that is defined via implicit syntax. The same issue was fixed in Cats code base - see typelevel/cats#2491 andtypelevel/cats#2614.
Proposed change can be considered as binary compatible - unless someone used
GenApplyLensOps.value
in code which is unlikely. We can probably do a bit more and replacetoGenApplyLensOps
andGenApplyLensOps
with single implicit class - as Scala looks to be not instantiating it for macro based syntax. But this change can break some code using GenApplyLensOps directly, so for now I'm just making.value
private and replace access to it in macro with pattern matching on tree.