Skip to content

Generated apply methods don't have default parameters #19201

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
mbovel opened this issue Dec 5, 2023 · 1 comment · Fixed by #19464
Closed

Generated apply methods don't have default parameters #19201

mbovel opened this issue Dec 5, 2023 · 1 comment · Fixed by #19464
Assignees
Labels
area:desugar Desugaring happens after parsing but before typing, see desugar.scala itype:bug
Milestone

Comments

@mbovel
Copy link
Member

mbovel commented Dec 5, 2023

Reported by DallogFheir on StackOverflow.

Let person.scala be:

class Person(
    val firstName: String,
    val lastName: String,
    val birthYear: Int = -1,
    val address: String = ""
):
  // Works if remove this constructor
  def this() = this("John", "Doe")

@main
def main() =
  val p1 = Person("John", "Doe")
  val p2 = Person("Josh", "Doe", 1912, "Main Street")

Running with scala-cli run -S 3.nightly applyDefaults2.scala, we get:

[error] ./applyDefaults2.scala:11:12
[error] None of the overloaded alternatives of method apply in object Person with types
[error]  (): Person
[error]  (firstName: String, lastName: String, birthYear: Int, address: String): Person
[error] match arguments (("John" : String), ("Doe" : String))
[error]   val p1 = Person("John", "Doe")
[error]            ^^

Expectation: should work.

Possible explanations as discussed with @odersky and posted to StackOverflow:

The problem appears to stem from the interaction between universal apply methods and default parameter values. Essentially, the compiler automatically generates apply methods that forward to constructors in the companion object of classes. However, these methods do not include default parameters. Hypothesis: when there is a single constructor, the compiler is able to trace back to the original constructor's default parameters, but not when there are multiple constructors.

@mbovel mbovel added itype:bug area:desugar Desugaring happens after parsing but before typing, see desugar.scala Spree Suitable for a future Spree labels Dec 5, 2023
@scala-center-bot
Copy link

scala-center-bot commented Jan 14, 2024

This issue was picked for the Issue Spree No. 41 of January 16th, 2024 which takes place in 2 days. @dwijnand, @KuceraMartin, @aherlihy will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

@dwijnand dwijnand self-assigned this Jan 16, 2024
@mbovel mbovel removed the Spree Suitable for a future Spree label Jan 30, 2024
@Kordyjan Kordyjan added this to the 3.4.1 milestone Feb 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:desugar Desugaring happens after parsing but before typing, see desugar.scala itype:bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants