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

Inconsistency between 0.9.25 and 0.9.26 versions - possible regression #990

Closed
lewapek opened this issue Jul 8, 2021 · 4 comments · Fixed by #994
Closed

Inconsistency between 0.9.25 and 0.9.26 versions - possible regression #990

lewapek opened this issue Jul 8, 2021 · 4 comments · Fixed by #994

Comments

@lewapek
Copy link

lewapek commented Jul 8, 2021

Hey,
it seems that there is inconsistency between 0.9.25 and 0.9.26 versions of the library
Below you can find code snippet showing that with versions <= 0.9.25 Concrete type could be passed to function which expects Base
With 0.9.26 it's not possible (compilation error)
Is that intentional?

  type BaseRefinement = And[Size[Equal[10]], Forall[LetterOrDigit]]
  type Base = String Refined BaseRefinement

  type ConcreteRefinement = And[StartsWith[W.`"001"`.T], BaseRefinement]
  type Concrete = String Refined ConcreteRefinement

  def funBase(b: Base): Unit = println(b)
  def funConcrete(c: Concrete): Unit = println(c)

  val b: Base = "1234567890"
  val c: Concrete = "0012345678"

  funBase(b)
  funBase(c) // with 0.9.26 doesn't compile, with 0.9.25 works fine

  //    funConcrete(b) // doesn't compile on both versions - that's fine
  funConcrete(c)

Full code snippet ready to compile can be found here (https://gist.github.com/lewapek/3cbf003a000bbe9bf479607e9967d201)

Thanks :)

@lewapek lewapek changed the title Inconsistency between 0.9.25 and 0.9.26 versions Inconsistency between 0.9.25 and 0.9.26 versions - possible regression Jul 8, 2021
@fthomas
Copy link
Owner

fthomas commented Jul 8, 2021

#927 by @matwojcik was the only change in 0.9.26 that was not a version bump. Maybe this issue is related to that change.

@matwojcik
Copy link
Contributor

Indeed something got broken during implicits resolution, because the Refinement @lewapek created were pretty complex (nested Ands, Ors). I've moved my instances to lower level implicits and it seem to help, see #994.

@lewapek
Copy link
Author

lewapek commented Jul 12, 2021

Thanks @matwojcik

@thiloplanz
Copy link

We are also suffering from this regression.

Is the patch from #994 working? If so, can we get this released?

fthomas added a commit that referenced this issue Jul 19, 2021
Move inferences to lower level of implicits, fixes #990
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 a pull request may close this issue.

4 participants