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

Jump to bottom

Curried and overloaded method ambiguity #2383

Closed
scabug opened this issue Sep 23, 2009 · 4 comments
Closed

Curried and overloaded method ambiguity #2383

scabug opened this issue Sep 23, 2009 · 4 comments

Comments

@scabug
Copy link

scabug commented Sep 23, 2009

When overloading a method with a curried version, the compiler is unable to distinguish, even thought a curried version requires a trailing underscore.

def foo(b: Bar) {
// do something
}

def foo(b: Bar) (f: (Bar) => Baz) {
// do something else
}

Calling:

foo(bar)

causes the compiler to issue an ambiguity error. But had I wanted the curried version, I would (in fact, I'm required to) write:

foo(bar) _
@scabug
Copy link
Author

scabug commented Sep 23, 2009

Imported From: https://issues.scala-lang.org/browse/SI-2383?orig=1
Reporter: @nilskp

@scabug
Copy link
Author

scabug commented Sep 29, 2009

@odersky said:
That's as speced. To change this, we'd need a proposal for a revised spec, and its diff to the current one. I suspect, however, the new spec would complicate overloading quite a bit, and therefore would most likely be rejected.

@scabug
Copy link
Author

scabug commented Sep 29, 2009

@nilskp said:
I would like to know more. What part of the spec exactly?

@scabug scabug closed this as completed May 18, 2011
@scabug
Copy link
Author

scabug commented Mar 27, 2015

Richard Bradley (richard.bradley) said (edited on Mar 27, 2015 12:58:31 PM UTC):
So methods defined in this pattern are never actually invokeable, by design?
That seems odd.

Perhaps the compiler should issue a warning when encountering methods defined in this pattern to warn users that they will not actually be useable.

See etorreborre/specs2#349

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@scabug