Skip to content

Parameter untupling can be prevented with indirection #21778

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

Closed
coreywoodfield opened this issue Oct 16, 2024 · 3 comments
Closed

Parameter untupling can be prevented with indirection #21778

coreywoodfield opened this issue Oct 16, 2024 · 3 comments
Labels
area:match-types area:typer itype:bug stat:fixed in next The issue was fixed in Next and only still applies to LTS.

Comments

@coreywoodfield
Copy link

Compiler version

3.3.4

Minimized code

doesn't work:

trait Foo {
  type T <: Tuple
  type Mapped = Tuple.Map[T, Option]

  def map[A](f: Mapped => A): Unit = ???
}
class Bar extends Foo {
  override type T = (Int, String)
  // doesn't compile
  map { (int, string) =>
    ()
  }
}

works:

trait Foo {
  type T <: Tuple
  
  def map[A](f: Tuple.Map[T, Option] => A): Unit = ???
}
class Bar extends Foo {
  override type T = (Int, String)
  // compiles fine
  map { (int, string) =>
    ()
  }
}

Output

-- [E086] Syntax Error: .../Test.scala:39:22 
39 |  map { (int, string) =>
   |        ^
   |        Wrong number of parameters, expected: 1
40 |    ()
   |----------------------------------------------------------------------------
   | Explanation (enabled by `-explain`)
   |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   | The function literal
   |
   |     (int, string) =>
   |   {
   |     ()
   |   }
   |
   | has 2 parameters. But the expected type
   |
   |     Bar.this.Map => Unit
   |
   | requires a function with 1 parameters.
    ----------------------------------------------------------------------------
one error found

Expectation

I expect parameter untupling to occur regardless of type indirection, as long as the type can be fully resolved where the parameter untupling should occur. Instead, parameter untupling does not always occur. I think the alias and the match type are both playing a role here: simply having two aliases that refer to a concrete tuple type (type T = (Int, String), type X = T) does not prevent parameter untupling

@coreywoodfield coreywoodfield added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Oct 16, 2024
@WojciechMazur
Copy link
Contributor

WojciechMazur commented Oct 16, 2024

This issue was fixed in Scala Next releases, to be exact it now works correctly since release 3.5.0.
Bisect points it was fixed by #19871
Scala 3.3.4 contains all safe-to-backport changes introduced until Scala 3.5.1. It means that we're not able to fix this issue in the LTS without breaking binary/source compatibility in the LTS line, introducing new regressions, or it depended on other changes that failed this criteria.

@WojciechMazur WojciechMazur added area:typer stat:fixed in next The issue was fixed in Next and only still applies to LTS. area:match-types and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Oct 16, 2024
@Gedochao
Copy link
Contributor

Seems like it's a wontfix for the LTS.
Closing this, nothing to do here.

@som-snytt
Copy link
Contributor

Duplicates #19821

@som-snytt som-snytt closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:match-types area:typer itype:bug stat:fixed in next The issue was fixed in Next and only still applies to LTS.
Projects
None yet
Development

No branches or pull requests

4 participants