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

Calling java functions without parentheses results in lambdas instead of compilation errors #16820

Closed
scf37 opened this issue Feb 2, 2023 · 1 comment · Fixed by #16892
Closed
Assignees
Milestone

Comments

@scf37
Copy link

scf37 commented Feb 2, 2023

Compiler version

3.1.3 and later

Minimized code

val p = java.nio.file.Paths.get(".")
println(p.toRealPath)

Output

Playground$$$Lambda$20996/0x00000008047106c8@3cdbaf1c

Expectation

Compilation error (like before) or file path (like what I want). Calling java functions without parentheses was my good habit that suddenly turned out to be bad one.

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

This is due to improvement #14397

Welcome to Scala 3.1.2 (19, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.

scala> "".charAt
val res0: Int => Char = Lambda$1275/0x000000080146c3e0@7cdfa824

scala> java.nio.file.Paths.get(".").toRealPath
-- [E081] Type Error: --------------------------------------------------------------------------------------------------
1 |java.nio.file.Paths.get(".").toRealPath
  |^
  |Missing parameter type
  |
  |I could not infer the type of the parameter x$0 of expanded function:
  |x$0 => $1$.toRealPath(x$0*).
1 error found

scala> "".formatted
-- [E081] Type Error: --------------------------------------------------------------------------------------------------
1 |"".formatted
  |^
  |Missing parameter type
  |
  |I could not infer the type of the parameter x$0 of expanded function:
  |x$0 => "".formatted(x$0*).
1 error found

versus

Welcome to Scala 3.2.2 (19, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.

scala> "".charAt
val res0: Int => Char = Lambda$1315/0x0000000801494000@5feb82b3

scala> "".formatted
val res1: Seq[Object] => String = Lambda$1389/0x00000008014d1000@42cfd794

scala> java.nio.file.Paths.get(".").toRealPath
val res2: Seq[java.nio.file.LinkOption] => java.nio.file.Path = Lambda$1448/0x00000008014d1798@5b5b8730

Also in 2.13, "empty application" does not apply to varargs:

Welcome to Scala 2.13.10 (OpenJDK 64-Bit Server VM, Java 19).
Type in expressions for evaluation. Or try :help.

scala> "".charAt
          ^
       error: missing argument list for method charAt in class String
       Unapplied methods are only converted to functions when a function type is expected.
       You can make this conversion explicit by writing `charAt _` or `charAt(_)` instead of `charAt`.

scala> "".formatted
          ^
       error: missing argument list for method formatted in class String
       Unapplied methods are only converted to functions when a function type is expected.
       You can make this conversion explicit by writing `formatted _` or `formatted(_)` instead of `formatted`.

scala> "".formatted()
val res2: String = ""

@mbovel mbovel added compat:java and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Feb 6, 2023
odersky added a commit to dotty-staging/dotty that referenced this issue Feb 12, 2023
A unary varargs method sits between nullary methods that sometimes get a () argument inferred
(i.e. for methods coming from Java) and other methods that can be eta expanded. The safest
strategy for them is to do neither, and expect either an explicit expected function type,
or an explicit argument. That's also what Scala 2 does.

Fixes scala#16820

Reclassifies scala#14567 to be a neg test (with the error message suggested in the original issue
for scala#14567)
odersky added a commit that referenced this issue Feb 19, 2023
A unary varargs method sits between nullary methods that sometimes get a
() argument inferred (i.e. for methods coming from Java) and other
methods that can be eta expanded. The safest strategy for them is to do
neither, and expect either an explicit expected function type, or an
explicit argument. That's also what Scala 2 does.

Fixes #16820

Reclassifies #14567 to be a neg test (with the error message suggested
in the original issue for #14567)
@Kordyjan Kordyjan added this to the 3.3.1 milestone Aug 1, 2023
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.

5 participants