Re: Distinguishing case class members

I’m concerned that the rarity of needing to do this may make it unreasonable to maintain such a feature. I’ve been doing Scala since 2011 and have maybe needed to do that once? How frequently do you find yourself wanting this?

—
Matt Farmer | Blog <http://farmdawgnation.com/> | Twitter <https://twitter.com/farmdawgnation>
GPG: CD57 2E26 F60C 0A61 E6D8  FC72 4493 8917 D667 4D07

> On Dec 26, 2015, at 5:22 AM, Peter Empen <[email protected]> wrote:
> 
> 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] <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

-- 
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.