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

Type mismatch with a + operator in an extension method of a newtype #12960

Closed
hmemcpy opened this issue Feb 26, 2024 · 8 comments
Closed

Type mismatch with a + operator in an extension method of a newtype #12960

hmemcpy opened this issue Feb 26, 2024 · 8 comments

Comments

@hmemcpy
Copy link

hmemcpy commented Feb 26, 2024

Scala version: 2.13.13 (under Xsource:3)

The following code, under Xsource:3 with Scala 2.13.13:

  type Point = Point.Type
  object Point {
    type Type <: Any
    def apply(x: Int): Point = x.asInstanceOf[Point]

    implicit final class MyExt(val myInt: Point) extends AnyVal {
      def +(other: Int): Point = ???
    }
  }

  val p = Point(3)
  val p2 = p + 2

Produces the following error:

type mismatch;
 found   : Int(2)
 required: String
    val p2 = p + 2

Problem

The problem started after upgrading to Scala 2.13.13. We use the scala-newtype library, and some of our newtypes that define a + operator started to fail with the error above.
The code snippet is the simplified "expanded" version of the newtype macro that also exhibits the problem:

@newtype case class Point(i: Int)
  def +(other: Int): Point
}

In all previous versions, this code compiled fine under Xsource:3.

@SethTisue
Copy link
Member

As of 2.13.13, -Xsource:3 only causes warnings to be omitted; it never (unless we missed something!) causes other behavior changes.

So it seems expected to me that if the code used to require -Xsource:3 to compile, it might now instead require -Xsource:3-cross, which does enable behavior changes.

@SethTisue
Copy link
Member

SethTisue commented Feb 26, 2024

By the way, we have done our best to be clear about this in the 2.13.13 release notes as well as the PR description at scala/scala#10573 — if you think further edits would help make the situation clearer, let us know.

@som-snytt
Copy link

I confirmed that it needs -Xsource:3-cross.

@som-snytt som-snytt closed this as not planned Won't fix, can't repro, duplicate, stale Feb 26, 2024
@hmemcpy
Copy link
Author

hmemcpy commented Feb 26, 2024

Yeah, was about to update that it does work under 3-cross. Thanks for checking!

@som-snytt
Copy link

@hmemcpy
Copy link
Author

hmemcpy commented Feb 26, 2024

Right, sorry, I deleted my comment. We can't switch to 3-cross (yet) because of the overridden member type inference change - it causes a lot of type mismatches for us (because we omit type signatures practically everywhere) and it doesn't play nice with ZIO's contravariant R parameter (something I encountered here #12707). Unfortunately, fixing it on our side is too "expensive" in terms of changes...

Anyway, with the Xsource:3 changes I am finally able to upgrade our codebase to the latest Scala 2.13.13 without (many) additional changes, except this one (and another one having to do with infix operators beginning on a new line).

Anyway, thanks for checking, let's keep this issue closed.

@som-snytt
Copy link

We didn't mention that -Yno-predef also suffices for the example; or -Yimports to provide a custom Predef that omits what is undesirable and supplies what is necessary.

@lrytz
Copy link
Member

lrytz commented Feb 28, 2024

because we omit type signatures practically everywhere

Is there a technical reason or would everything work with explicit types?

fixing it on our side is too "expensive" in terms of changes

With 2.13.13 you could try -quickfix:msg=under -Xsource:3-cross, the inferred type changes to have the compiler add the result types

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

No branches or pull requests

4 participants