diff options
| author | Adriaan Moors <adriaan@lightbend.com> | 2017-02-26 16:01:37 -0800 |
|---|---|---|
| committer | Adriaan Moors <adriaan@lightbend.com> | 2017-04-05 11:27:13 -0700 |
| commit | eed52216c634a6d73f737358ed6d6c5855452603 (patch) | |
| tree | 49f872a0c32653776309731a9048d2896cb520c1 /spec/05-classes-and-objects.md | |
| parent | 18157b92a43b2ab12a856fe15eb9d00d1e1bc0c6 (diff) | |
| download | scala-eed52216c634a6d73f737358ed6d6c5855452603.tar.gz scala-eed52216c634a6d73f737358ed6d6c5855452603.tar.bz2 scala-eed52216c634a6d73f737358ed6d6c5855452603.zip | |
Allow user-defined `[un]apply` in case companion
Don't emit a synthetic `apply` (or `unapply`) when it would
clash with an existing one. This allows e.g., a `private apply`,
along with a `case class` with a `private` constructor.
We have to retract the synthetic method in a pretty roundabout way,
as we need the other methods and the owner to be completed already.
Unless we have to complete the synthetic `apply` while completing
the user-defined one, this should not be a problem. If this does
happen, this implies there's a cycle in computing the user-defined
signature and the synthetic one, which is not allowed.
Diffstat (limited to 'spec/05-classes-and-objects.md')
0 files changed, 0 insertions, 0 deletions