Sounds good. Yep I plan to work actively on it. Us...

# pattern-matching

[mattmoore]

Sounds good. Yep I plan to work actively on it. Usually weekends are my best time, sometimes on weeknights. I’m able to continue this weekend.

Understandable about the controversies. I think sometimes I take for granted the situation with Scala where I don’t have as much pushback on these concepts. But with pattern matching, I think that if folks can see some decent examples of how it helps with code reduction and can improve readability (I think Nico’s KEEP examples have some good examples of this as a starting point), they might be willing to adopt it more. At the end of the day, while I have enthusiasm for these concepts, I realize that a lot of engineers care about what makes their job easier. If concepts are framed with that in mind, it seems to be easier to get folks to adopt things.

In any case, even if the Kotlin community at large doesn’t end up adopting these features, I don’t consider it a loss. It’s a good learning experience for me on a personal level and I view the knowledge I’ll gain from this as useful for other concepts I have in mind.

While Java has its own proposal, I don’t necessarily feel that this feature has to wait for that, or even needs to necessarily clash. Even if the Java proposal has some conflicts, there’s no reason why we can’t perhaps just adapt the Kotlin version to it or, if we end up with something more flexible than Java (like with an optics-style approach with fields or even some other capabilities as of yet unknown) that we shouldn’t just keep ours intact, at least syntactically. Perhaps we might have to change how it interfaces with the rest of the compiler but I don’t see that as a problem. At least not a technical one. I understand though if there ends up being a controversy around it. The toughest problems to solve are often people, not necessarily technology.