Skip to content
This repository has been archived by the owner. It is now read-only.

Decide what kind of equality to use for maps and sets, and other operations #246

Closed
odersky opened this issue Sep 16, 2017 · 5 comments
Closed
Labels

Comments

@odersky
Copy link
Contributor

@odersky odersky commented Sep 16, 2017

See: https://contributors.scala-lang.org/t/can-we-get-rid-of-cooperative-equality/1131/34

If we migrate away from co-operative equality, new collections should not use it anymore and should use equals and hashCode instead. Even if we do not migrate away, it might still be preferable to do this for performance reasons.

Same holds for operations such as indexOf on Seq.

@julienrf
Copy link
Contributor

@julienrf julienrf commented Sep 16, 2017

A note about that: for TrieMap it is possible to use a custom equality. Do we want to generalize that? I think that would make sense. What is the performance overhead, though?

@Ichoran
Copy link
Contributor

@Ichoran Ichoran commented Sep 17, 2017

It would be great if we could implement custom equality that didn't have a performance penalty beyond what scala.runtime.BoxesRunTime.equals2 and friends have. Is there an easy way we can test this? Maybe run the performance test on TrieMap with the custom equality commented out and regular == equality used in its place?

@julienrf julienrf added this to the 0.6.0 milestone Sep 28, 2017
@julienrf julienrf added ready and removed ready labels Sep 28, 2017
@julienrf
Copy link
Contributor

@julienrf julienrf commented Oct 3, 2017

I think what we will do on the collections will depend on what we decide about cooperative equality in general in Scala?

@odersky
Copy link
Contributor Author

@odersky odersky commented Oct 5, 2017

I don't have high hopes for cooperative equality in Scala. We might still introduce it in Dotty but that would then be transparent as gar as the collections are concerned. I agree that customizing equality is a win. Easy to do for mutable collections - just expose an overridable equals and hashCode operation. For immutable it looks more cumbersome to do it, though. We'd probably need an extra parameter (implicit or explicit).

@julienrf julienrf modified the milestones: 0.6.0, 0.7.0 Oct 23, 2017
@julienrf julienrf removed this from the 0.7.0 milestone Nov 20, 2017
@julienrf
Copy link
Contributor

@julienrf julienrf commented Jan 3, 2018

As long as Scala 2.13 keeps using cooperative equality, I think the collections should keep using cooperative equality as well.

@julienrf julienrf closed this Jan 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants