I just saw the email announcement of `value class`...

# arrow

[CLOVIS]

I just saw the email announcement of value class and it sounds like something Arrow would be really interested in (immutable classes that have mutators that return copies). Do you have plans to use these features? They seem to clash with Lens, but maybe they could work well together?

[Satyam Agarwal]

How can I subscribe to this email list ? Can you paste a copy of that email please ?

[simon.vergauwen]

Yes, I'd also love to know how you got that as an email announcement 😮

[simon.vergauwen]

value class is absolutely something we're interested in! And the deep mutation part does seem to clash a bit with the Optics DSL but it might also served as an inspiration point I think. The Optics DSL has been discussed several time with some JB people.

If there is a better solution in Kotlin, we'll just deprecate the Arrow variant in favor of the Kotlin way of doing this.

[okarm]

@simon.vergauwen It's the Kotlin Blog.

https://blog.jetbrains.com/kotlin/

Particularly https://blog.jetbrains.com/kotlin/2021/02/new-language-features-preview-in-kotlin-1-4-30/

And in that there was an inconspicuous link to
https://github.com/Kotlin/KEEP/blob/master/notes/value-classes.md

cc @Satyam Agarwal

[simon.vergauwen]

😅 Thanks!

[CLOVIS]

Sorry, I completely forgot how to subscribe to it 😅

“In order for immutability to shine in Kotlin, updates to immutable structures should not be more verbose in source code than updates of mutable data.”
That sounds like something we can get hyped for 👍

[simon.vergauwen]

Absolutely! That's (one of) the biggest points of Optics in Arrow atm.

[CLOVIS]

Whenever you get some time to read it (it's very long 😅), I'd be interested in your thoughts and if whether Optics can be a complement or if it's completely replaced (of course that proposal is far future, but still)

[julian]

Seems like mutating functions on value classes hasn't been implemented yet.

[CLOVIS]

Oh no, if I understand the document correctly so far the only thing they did is add the value keyword and the JvmInline annotation. I don't think we'll see value classes soon, but it's really interesting to know what they are thinking about.

[simon.vergauwen]

Yes, I don't expect this to be something to be around the corner either.

[simon.vergauwen]

I've only read it briefly but my initial thoughts are that this might replace Optics, but it depends on a lot of factors. Is this only going to be for value class or also data class and sealed class. Will this also include special support for things like kotlin.collections etc.

I think we'd have to sacrifice the compositional properties of Optics for promoting this instead as well.

[simon.vergauwen]

I need to read the document in more detail, and perhaps also ask some question on the KEEP itself. That could perhaps spark some new ideas and discussions which is always good.

[simon.vergauwen]

If I have time to read it more I'll try to remember to share my thoughts with you @CLOVIS;)

[CLOVIS]

@simon.vergauwen further in the document they show syntax for deeply-immutable mutation and they explain multiple times that that syntax only works for value class because of ambiguities. The only issue I think is that the migration of List etc is going to be complicated, if at all possible (they touch on this as well).

They also mention a AnyValue type that would be the common ancestor to all value class, I wonder where it should be positioned compared to Any? Mathematically it should probably be above it (since Any = AnyValue + identity) but that sounds like it could break some code? Also, having AnyValue as a parameter wouldn't allow the compiler to copy objects in all cases...

[simon.vergauwen]

Oh AnyValue that seems very Scala like I'm quite surprised about that 😅 A bit weird this feature would be for value class only since data class suffers from the exact same problem they explain in their rationale.

[simon.vergauwen]

In that case, I don't think Optics will become obsolete but we'll need to figure out a way to them complement each other in a nice way 🙂

[CLOVIS]

I think (but of course I could be completely wrong) that their plan for the future is to fade out data class (we would only use them for mutable data, which in theory should be fairly rare).

It sounds like it could work very well when it's implemented, but the migration sounds like a ton of work, it's a big step for the language.

[CLOVIS]

I've always felt Kotlin lacked a “deep constant” keyword though, so I'm very interested ^^

[CLOVIS]

Actually this is probably the solution to Kotlin Native's freeze problem: what if they made it so you can only share value classes between threads? Then, it would be a compile-time feature, and not a runtime feature.

[simon.vergauwen]

Oh, that would actually be pretty cool but I'm not sure how that ties in with the JVM tho. That would add a restriction to value classes that the JVM doesn't restrict. I'd love it but not sure if everyone would 😀

[CLOVIS]

I think it's better than the current “your code works on all platforms only if you don't share mutable state, because your environment is a JVM and you definitely forgot freeze exists” 🤔