is it weird/unidiomatic to omit the braces in an `...

# getting-started

[y]

is it weird/unidiomatic to omit the braces in an else case for single-expressions, for brevity/syntax-sugar? for example

if (something) {
  do_thing()
} else when (somethingElse) {
  A -> a()
  B -> b()
  C -> c()
}

[Rob Elliot]

I increasingly tend to turn all if / else into when because I think it balances nicer...

when {
  something -> do_thing()
  else -> when (somethingElse) {
    A -> a()
    B -> b()
    C -> c()
  }
}

[Youssef Shoaib [MOD]]

Especially here, this is very idiomatic.

[Rob Elliot]

For clarity I am 99.99% sure @Youssef Shoaib [MOD] is endorsing @y’s syntax not mine.

[y]

@Rob Elliot your syntax is different, I think it's very non-controversial

[Youssef Shoaib [MOD]]

Indeed I was, but your approach is acceptable too, in fact I'd probably prefer it.
Also turns out with the when Guards feature you can do this:

when (somethingElse) {
  else if something -> do_thing()
  A -> a()
  B -> b()
  C -> c()
}

Of course, that executes somethingElse unconditionally

[y]

wait, what's that? since when do we have when guards?!

[y]

https://androidengineers.substack.com/p/guard-conditions-in-when-statements

woah

[Youssef Shoaib [MOD]]

It's experimental, needs a compiler argument to activate, but yeah it's amazing. One step closer to idiomatic pattern-matching!

[phldavies]

https://pl.kotl.in/R3lr3KgNT amazingly it compiles - kinda surprised with the "else" being first that it's happy but it makes sense for "else if"

[Youssef Shoaib [MOD]]

I agree that it looks "weird", but I think we'll get used to it. Apparently, they can't drop the else because it would cause parser issues (because if (foo) x else y vs if (foo) makes it ambiguous)
To be frank, I didn't know about this and had been doing:

// Assuming somethingElse : T
when (somethingElse) {
  is T if something -> do_thing()
  A -> a()
  B -> b()
  C -> c()
}

[y]

every day that decreases friction from writing Rust to writing Kotlin makes me happier. thank you Kotlin people.

[y]

...now to wait until $work even makes the jump to Kotlin 2.x

[y]

I hate having to choose between the pattern-matching when-with-value syntax and the more-lenient but non-exhaustive when-without-value syntax (edit: so this change is of course, welcome)

[y]

however @phldavies I must admit this else-first syntax is... jarring

[phldavies]

I'm ok with being astonished with syntax so long as I can reason about the why of it and codify that in my "framework of understanding" if you will.
It is, after all, the principal of least astonishment not no astonishment 🙂

[y]

looking at the docs though...
> If you use guard conditions in when statements without an else branch, and none of the conditions matches, none of the branches is executed.
>
> Otherwise, if you use guard conditions in when expressions without an else branch, the compiler requires you to declare all the possible cases to avoid runtime errors.
...I'm not sure I follow. is there exhaustive testing with guards, or isn't there?

[y]

is this a typo, and exhaustive checks are only for completely guard-less when expressions?

[Youssef Shoaib [MOD]]

A guarded expression is ignored w.r.t. exhaustiveness checking. For exhaustiveness, it's as if it wasn't there for the compiler

[y]

@Youssef Shoaib [MOD] so it is indeed this typo?

[y]

(also, this doc seems to mix up "statement" and "expression")

[Klitos Kyriacou]

For those who are stuck on older versions or don't want to use experimental features, my take on idiomatic if statements is that if you have braces in the if, put braces in the else and vice versa.

[phldavies]

I think the example above makes perfect sense when you consider an else if is the same structure.

[y]

@phldavies personally my (potential!) objections with something like this are not about if it makes sense, but if it (in no particular order)
1. looks "at home" with a language/is not "jarring", aesthetically
2. easy to mentally parse, especially when you first encounter it
3. does not introduce new ways to do something, especially when it is already idiomatic to do said something in a similar-but-slightly-different way. unless this new syntax sugar is significantly better/shorter than what currently exists.

[y]

to be clear, I do want expressiveness, I do obviously welcome this particular kind of syntax, and Kotlin has... not been very strict about that last one

[y]

@Klitos Kyriacou that's what I ended up doing. especially because we apparently lint against this. I guess as a safeguard from overzealous bikeshedders such as myself (no sarcasm intended, this kind of syntax I'm suggesting here is not worth it if is not adopted by other people in the project)