His take was “If I have an `x` and call `copy` on ...

# announcements

[jmccance]

His take was “If I have an x and call copy on x, I expect to be able to call the same functions on the copy as I could on x.”

[adam-mcneilly]

I'm with this take tbh

[adam-mcneilly]

I understand your ask in the message before, but that's not how statically typed languages work. /shrug

[jmccance]

I mean, Haskell and Scala both work that way. They’re statically typed.

[Andreas Sinz]

I don't see a reason why kotlin isn't able to support it (it just hasn't been implemented yet)

[jmccance]

(“That way” meaning they allow polymorphic copies.)

[Andreas Sinz]

but I guess it can get complicated to implement it, for example:

data class Foo<A>(val bar: A, val baz: A)

val fooString = Foo("hello", "world")
val fooInt = fooString.copy(bar = 5) //Does it work? What is <A> afterwards?

[adam-mcneilly]

Ahh I don't have any experiences with those languages.

[jmccance]

@Andreas Sinz Oh, interesting. Let me check what Scala does in that case. I’d assume a compile error of some sort.

[jmccance]

Oh, it just unifies up to Any. Unsurprising, but bleh.

[jmccance]

scala> case class F[A](x: A, y: A)
defined class F

scala> val stringstringF = F("asdf", "zxcv")
stringstringF: F[String] = F(asdf,zxcv)

scala> val stringIntF = stringstringF.copy(x = 1)
stringIntF: F[Any] = F(1,zxcv)

[jmccance]

Same behavior would work for Kotlin, though.

[madorb]

i still stand by that not matching my personal semantic definition of what a copy is. A copy of an X to me makes sense to also be an X. but that's just about the naming, i definitely agree that the functionality could be useful. just rename the original method from copy to change and 👍

[madorb]

cuz even the existing method ain't really a "copy"

[jmccance]

We can rename “flatten” to “smoosh” while we’re at it. 🙂

[madorb]

perf

[madorb]

i'm sure groovy has some bizarre name for the operation