Generate a readable error message if syntectic copy method clashes with user-defined one

[DarkDimius]

Syntectic copy method in case classses has default arguments.
And leads to compilation error if user had also defined a copy method with default arguments as in dotty-staging@202a377#diff-ca3386647f5386b6f70e99f1a9e188cdR1982

I guess desugaring should not synthesize a copy method if user had defined any method named copy.

[DarkDimius]

Could manifest itself either as an error-message during checking or as a data-race assertion. Both can be seen https://travis-ci.org/lampepfl/dotty/builds/39506385

[DarkDimius]

After a discussion with @odersky:
That's intended. Logic of deciding if copy method should be generated is too involved an to hard to maintain. And copy method would be always generated. Instead we could work on error message in future.

[retronym]

The copy method subverts attempts to use private constructors for case
classes so being able to disable its generation is a useful idiom.

Jason

On Monday, November 3, 2014, Dmitry Petrashko [email protected]
wrote:

After a discussion with @odersky https://github.com/odersky:
That's intended. Logic of deciding if copy method should be generated is
too involved an to hard to maintain. And copy method would be always
generated. Instead we could work on error message in future.

—
Reply to this email directly or view it on GitHub
#209 (comment).

[nicolasstucki]

The current error message for this is

case class Foo(a: Int) {
  def copy(i: Int): Foo = ???
}

-- Error: Foo.scala:1:21 -------------------------------------------------------
1 |case class Foo(a: Int) {
  |                     ^
  |           cannot merge
  |             method copy: (a: Int): Foo  and
  |             method copy: (i: Int): Foo;
  |           they are both defined in class Foo but have matching signatures
  |             (a: Int): Foo and
  |             (i: Int): Foo
  |           when seen as members of Foo(Foo.this)
-- Error: Foo.scala:2:6 --------------------------------------------------------
2 |  def copy(i: Int): Foo = ???
  |      ^
  |      method copy is already defined as method copy: (a: Int): Foo
  |       (the definitions have matching type signatures)

We should catch this situation earlier and tell the user why this synthesized method exists.

We also need to do this for other syntesized methods such as equals hashCode, apply, unapply, ...

[odersky]

@retronym

The copy method subverts attempts to use private constructors for case
classes so being able to disable its generation is a useful idiom.

But it seems case classes with private constructors have public apply methods, so there's no protection afforded by this. Except if we make the apply method private as well.

[odersky]

Leaving open, because we might rethink once more in detail how constructor accessibility affects methods created for a case class.