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

Import exported function from a library loses the default parameters #17930

Closed
JD557 opened this issue Jun 6, 2023 · 4 comments · Fixed by #20227
Closed

Import exported function from a library loses the default parameters #17930

JD557 opened this issue Jun 6, 2023 · 4 comments · Fixed by #20227

Comments

@JD557
Copy link
Contributor

JD557 commented Jun 6, 2023

Compiler version

3.3.0

Minimized code

lib.scala:

//> using scala "3.3.0"
//> using publish.name "defaultstest"
//> using publish.organization "eu.joaocosta"
//> using publish.version "0.1.0-SNAPSHOT"

package eu.joaocosta.defaultstest

object Foo {
  def foo(x: Int, y: Int = 5): Int = x + y
}

object Bar {
  export Foo.*
}

object App {
  println(Bar.foo(2)) // Works
}

Published with scala-cli --power publish local .\lib.scala

app.sc

//> using scala "3.3.0"
//> using lib "eu.joaocosta::defaultstest::0.1.0-SNAPSHOT"

import eu.joaocosta.defaultstest._

println(Foo.foo(2)) // Works
println(Bar.foo(2)) // Fails with "missing argument for parameter y of method foo in object Bar: (x: Int, y: Int): Int"

Output

[error] .\app.sc:7:9
[error] missing argument for parameter y of method foo in object Bar: (x: Int, y: Int): Int
[error] println(Bar.foo(2)) // Fails with "missing argument for parameter y of method foo in object Bar: (x: Int, y: Int): Int"
[error]         ^^^^^^^^^^

Expectation

The code should compile, using the default methods (same behavior as Foo.foo(2))

Notes

This seems very similar to #15031, although in my case the problem happens when importing a library.
No amount of clean/compile seems to fix it.

@JD557 JD557 added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Jun 6, 2023
@som-snytt
Copy link
Contributor

It reproduces on HEAD with separate compilation. That's running scalac on each file in turn, none of this scala-cli or sbt business.

JD557 added a commit to JD557/interim that referenced this issue Jun 10, 2023
@dwijnand dwijnand added area:export area:default-parameters and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Jun 12, 2023
@sbrunk
Copy link

sbrunk commented Jun 18, 2023

I just ran into this issue as well, while looking into ways to split an API with a many methods with default parameters into manageable chunks, but keeping a single entry-point to call these methods sbrunk/storch#29.

Export clauses seem like the perfect solution here, but given the large number of methods with default parameters, we'll have to wait until we have a fix for this issue.

@bishabosha
Copy link
Member

This seems like something we can maybe solve similar to constructor proxies (i.e. a constructor proxy is a fake inline apply method in a fake exported companion object), we could add fake default accessors to the fake exported companion object

@lbialy
Copy link

lbialy commented Apr 4, 2024

We have the same problem in Besom with exported functions losing default args.

bishabosha added a commit to dotty-staging/dotty that referenced this issue Apr 18, 2024
smarter added a commit that referenced this issue Apr 18, 2024
fix was implemented in #20167, so
close the issue with a test

fixes #17930
@Kordyjan Kordyjan added this to the 3.5.0 milestone May 10, 2024
WojciechMazur pushed a commit that referenced this issue Jul 5, 2024
WojciechMazur added a commit that referenced this issue Jul 5, 2024
Backports #20227 to the LTS branch.

PR submitted by the release tooling.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants