is there any effort to generate DSL for the data class

copy

method?

data class Foo(val bar: String)

val foo = Foo("bar")
foo.copy(bar = "bar1") // current

// could be this:
foo.copy {
   bar = "bar1"
}

What's the use-case?

You could write

foo.copy(
   bar = "bar1"
)

What do the curly braces gain you?

seen https://arrow-kt.io/docs/apidocs/arrow-optics/arrow.optics/copy.html or https://github.com/kopykat-kt/kopykat?

thanks! No specific use-case, just wondering if this could be generated in a more DSL-like style.

Okay.. There's really not much of a difference.. 🙂 and sometimes it's nice that there's a single way of doing things (easy for people to recognize what's going on)

@Endre Deak I’m the author of KopyKat, and I’m happy to add new features that would help in your use case 🙂

@Emil Kantis there is a big difference, though. Binary compatibility. The current copy has all properties as parameters, which means its signature changes every time the properties of the class change

And DSL would maintain binary compatibility?

Yes, because the signature would probably be something like:

fun copy(block: TheClassBuilder.() -> Unit)

Gotcha, not fully aware of how binary compatibility works but that makes sense. Thanks for explaining. 🙂

I honestly don't know. If you want to know more about data classes and binary compatibility, you can read Jake Wharton's article about it: https://jakewharton.com/public-api-challenges-in-kotlin/

Love this idea! DSL would also allow having local variables scoped inside the lambda. And it would be less verbose in some cases.

some.copy(count = some.count + 1)

vs

some.copy { count += 1 }

that is exactly what KopyKat does, albeit using a plug-in instead of being built in the language

Yeah, I'm aware of KopyKat - great library! Would love to have it as a language feature, though. 🙃

I think we're more likely to get

copy var

in the language, https://github.com/Kotlin/KEEP/blob/master/notes/value-classes.md#copyable-properties-of-immutable-types

I remember reading and debating a lot about this when it was first published. Now it just occurred to me that a "copyable property" is a funny name, because the property in question is literally the only thing that is NOT copied when we use the feature 😆 (we make a copy of the object, a copy of the value of all other properties, but not a copy of the copyable property that we're modifying)