Hey there, thanks for having me. I know there is a...

# language-proposals

[Johannes Zick]

Hey there, thanks for having me. I know there is a lot of discussion going on about pattern matching, and I know it's hard to do well and correct. But how about we start with a lightweight version, or really just syntactic sugar for destructuring?

val o = Option.just(1)

val i: Int = when (o) {
    is Some -> {
        val (value) = o
        value
    }
    else -> 0
}

val i: Int = when (o) {
    is Some(value) -> value
    else -> 0
}

This should be exactly equivalent, it could even result in exactly the same bytecode. It's easy to provide conversions in the IDE, one way or another. And it could give a hint if people really use this or if it's just a reflex to want everything others have (not even sure about myself, if we are being honest here).

It could be extended in the future, to also do type checks on destructured values (great for Pair), or other checks. Or not. By tying it to the is keyword for now, it's still open if this syntax will be extended, or dropped again, or will be replaced by something more powerful with a different keyword.

[Johannes Zick]

No interest or does everyone just agree with me...? 🤔 😅

[Dico]

I would argue the pattetn matching makes it a bit more readable

[Dico]

But that's not a science

[Ruckus]

I don't think that's actually "light weight". There's a lot of hidden complexity in your proposal, unless you only want pattern matching for this specific-yet-arbitrary Option type.

[Johannes Zick]

Light weight because I do not want any additional verifications. There are no checks done on the destructured values. It should generate the same bytecode in both examples here.

[Hanno]

Interested, yes, but guess my opinion is not too popular :) i have yet to see an example where pattern matching syntax is actually better than smart casting. Even your example, that was meant to motivate the feature, would look better with just smart cast and o.value.

[Johannes Zick]

IMHO if else pattern starts to become unreadable when you have more than those two branches. Consider sealed data classes with three or four types. You would normally use a when expression for four branches. So destructuring in the left side makes it much more natural.

[Johannes Zick]

I agree that smart casts help a lot already. It just makes the code easier to read, I believe.

[Hanno]

This is where i disagree, i don't think that destructuring makes (exactly those) cases more readable in any way. The properties are named already, the ability to use all properties of a smart casted object is just more natural and more simple here. This is where i would happily refrain from adding another feature to the language, because in 99% it doesn't improve things for me

[Johannes Zick]

Hmm, fair point, especially because destructuring is positional, so smart casting with properties is saver here. Did not consider that. Thanks!