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

Comments

Projects
None yet
3 participants
@odersky
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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?

@julienrf julienrf removed the in progress label Oct 4, 2017

@odersky

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

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.