Distinguishing case class members

Peter Empen <[email protected]> Sat, 26 Dec 2015 02:22:07 -0800 (PST)
Newsgroups gmane.comp.lang.scala
Message-ID <[email protected]>
Currently all parameters of the first parameter list go into the generated 
equals/hashCode/copy/unapply methods.
This works well for most cases but sometimes we need to *exclude* some 
parameters from equals/hashCode while keeping them copy and matchable.

Now, to relieve programmers from the burden of defining custom 
equals/hashCode in such situations, it would be great to have some direct 
means to advise the compiler which parameters should *not *go into 
equals/hashCode.

One approach could be to provide a specific member-level annotation for 
this purpose.
Another approach could be to let val-/non-implicit-members of any secondary 
parameter list become a parameter of copy automatically.
Maybe you have even a better approach.

What do you think about this proposal?

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.