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

non-sensible equality method doesn't account for overloading #6091

Closed
scabug opened this issue Jul 16, 2012 · 6 comments
Closed

non-sensible equality method doesn't account for overloading #6091

scabug opened this issue Jul 16, 2012 · 6 comments
Assignees
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Jul 16, 2012

scala> class X { def ==(other: String) = true }
defined class X

scala> new X == null
<console>:9: warning: comparing a fresh object using `==' will always yield false
              new X == null
                    ^
res14: Boolean = true

The culprit:

case Select(qual, name @ (nme.EQ | nme.NE | nme.eq | nme.ne)) if args.length == 1 =>
@scabug
Copy link
Author

@scabug scabug commented Jul 16, 2012

Imported From: https://issues.scala-lang.org/browse/SI-6091?orig=1
Reporter: @retronym
Affected Versions: 2.10.0
See #6090

@scabug
Copy link
Author

@scabug scabug commented Sep 7, 2012

@retronym said:
A similar example reported in #6328:

scala> object Foo { def eq(x:Int) = x }
defined module Foo

scala> Foo.eq(1)
<console>:9: warning: comparing values of types object Foo and Int using `eq' will always yield false
              Foo.eq(1)
                    ^
res0: Int = 1

@scabug
Copy link
Author

@scabug scabug commented Mar 4, 2013

@Ichoran said:
I am not entirely sure this is a bug. Such an override guarantees that equality is asymmetric as null==(new X) cannot possibly be anything but false.

If you want weird non-equality-like behavior in your relation, I do not think it is too much to ask to not call it == and therefore retain this warning.

@scabug
Copy link
Author

@scabug scabug commented Mar 5, 2013

Todd O'Bryan (toddobryan) said:
This also occurs when you use a Java library that defines an eq method. Since you have no control over whether the library decided to use that name, and there was no reason in Java for the developers not to have used that name, it seems like it should be possible to suppress the warning.

@scabug
Copy link
Author

@scabug scabug commented May 1, 2013

Jed Wesley-Smith (jedws) said:
We see the problem as outlined by Todd. It is library that we do not control and therefore Rex's suggestion doesn't apply. The warning is particularly misleading as the return type of the eq method in question is not Boolean.

@scabug
Copy link
Author

@scabug scabug commented May 17, 2013

@paulp said:
62cdd7ff90

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants