We should provide the `copy` method in all classes that meet the necessary requirements - not just i...

# language-proposals

[Michael Böiers]

We should provide the copy method in all classes that meet the necessary requirements - not just in data classes.

A good use case for that are database entities. They have a lot of attributes, and if you model the entities as immutable (which I like to do), you really need to define them as data classes just to get the copy method. But since database tables can have cyclical references, you then need to remember to override hashcode, equals and toString to get back to default behavior. Otherwise you will run into stack overflow errors at runtime. That kind of sucks, when all I ever needed was the damn copy method!

[ephemient]

have you seen Poko? https://github.com/drewhamilton/Poko
it does the opposite in some sense: it generates equals, hashCode, and toString, but not copy. however, it seems like it would be a good place to start experimenting with adding copy to non-data class types

[Michael Böiers]

Looks like Lombok! 🙂

[Michael Böiers]

I think that we should avoid annotations as much as possible. So how about

copyable class Foo(…)

[Michael Böiers]

Ideally the compiler would glean from the constructor(s) of the class if the copy method can be added, but since the Kotlin motto is “be explicit”, adding a modifier probably makes sense.

[Adam S]

Have you come across https://github.com/kopykat-kt/kopykat?

[Michael Böiers]

^ No, very nice! 🙂

[mcpiroman]

I'd like if the generated functionalities were chosen independently like in rust: #[derive(Copy, Clone, Hash, PartialEq)]

[Michael Böiers]

Yes, that would be absolutely cool!