Hi! I intend to start a new KEEP to finally bring ...

# arrow

[Nico]

Hi! I intend to start a new KEEP to finally bring pattern matching to Kotlin, or at least have some discussion about it. I took the trouble to write up a draft, and I would love some feedback or contributions on it.
I thought it would be popular with the Arrow community because it would make using the library's data types extremely natural. If you want to discuss this, I also posted in #language-proposals so ping me there!

[Hiosdra]

If Jetbrains will be against, maybe implement it in arrow-meta? It seems to be possible?

[Nico]

I am not familiar with Arrow-meta at all (I am under the impression it uses annotations to generate code). I don't see how you could implement it like that. A DSL would probably be the way, but when I made an attempt I could not manage to nicely match something with a name, and then use it with a variable of that name. I could only do it through lambdas and that would not allow to 'keep' the name.
At the end of the day, I think such a feature should make part of the core language. Having it be platform dependant or reliant on some library can be a big setback, and I just do not see a way to implement it in vanilla kotlin with the stuff we do have

[Nico]

If the proposal gains popularity though, I am planning to write a prototype transpiler to vanilla kotlin so we can play around and experiment with the feature

[Nico]

Do correct me on arrow-meta though, I really do not know about its potential wrt. what this would require 🙂

[Hiosdra]

I’m not 47deg guy, so I will only tell from my knowledge => meta is kind-of transpiler(it is compiler plugin), not annotation processor and it will be very likely possible to do multiplatform implementation of this keep

[Hiosdra]

And definitely I look forward to see this in core language, but there was discussion in kotlin forums back in 2017, which not give much optimism: https://discuss.kotlinlang.org/t/destructuring-in-when/2391

[Nico]

I have been browsing through the repo. Correct me if I am wrong, but arrow-meta does its job after lexing program but before building the AST? In that case, I do think it could be possible with a heavily modified syntax than that of my proposal, because I think the program does need to be valid from a grammar point of view

[Nico]

As for the forum discussion, I had seen it (it and others) and my takeaway was that there is desire for this feature but not 'badly enough' that anyone started a KEEP (probably thanks to smart casting). Additionally, I think it is safe to say that the usage of Kotlin has grown a lot since 2017. This proposal is a good way to see how 'wanted' pattern matching is today, so I guess we are about to find out how much optimism there is now around this!

[Hiosdra]

Yeah, I’m very for it. I’m professionally coding in Scala, but in hobby time -> in Kotlin and pattern-matching is my very thing that I miss in Kotlin 😕

[raulraja]

A variant of your pattern matching style can be acomplished with a destructor object and a version of unapply that returns a nullable version of the component and destructures it’s parts in a tuple

[raulraja]

it’s not the kind of runtime you’d want but you can make it compile

[raulraja]

Also as a general rule in the Kotlin compiler you can suppress most things except parsing errors and see where it takes you then intercept and codegen whatever you want

[raulraja]

I learned a few months ago that everything is suppresable which leads crazy syntax to travel all the way to the analysis phase

[Nico]

Glad to hear it @Hiosdra, make sure you voice your support when I submit the actual KEEP :))

[Nico]

I did not know you could mess that much with the compiler. That probably puts on the table a lot of stuff. Don't you think the parser might complain when we try to nest patterns though?

[Nico]

On second thought, we could just make the stuff we are matching on expressions, and then just look for identifiers in the parenthesis, nevermind!

[Nico]

It is definitely something I could undertake if the KEEP does not take us anywhere. But for the sake of getting the KEEP through, I think a bodge transpiler would be a better option as we probably want the same syntax as the proposal (though it can always change)