for exhaustivness
# getting-started
u
for exhaustivness
s
if
callButtonState
isn’t just an
Int
, sure, I guess, but why would this need to be exhaustive? these methods look like they’d return
Unit
, so the
when
doesn’t look like it’s assigning anything useful
u
I see your point, the question was just seeing if its possible
actually its what should happen after a button click, (and yea its enum, just int for speed writing the pseudocode)
s
it’s just that I can’t think of a case where you would both need to be exhaustive and have a branch that does nothing and therefore be cool with the fact that the when implicitly returns
Any
you wanna eliminate the
{}
when Kotlin lets you eliminate the case entirely
u
but then it will complaing about it not being exhaustive
s
?
u
linter I guess, warning..
s
when
is only required to be exhaustive when used as an expression
u
say I have enum { FOO, BAR, NONE } .. when(foo) ..
oh thats your point...
s
oh I see, it’s recommended to be exhaustive
u
..I still get warnings, even I am not returning from when
s
that’s a weird thing to have enabled by default
u
I honestly like it, but that formatting messes up niceness of code for me 😄
but I guess could have noop: Unit function
s
you may as well just have
case -> Unit
u
yea, because now when I thing about it, if when is expression I would need to return something anyways, not just Nothing, okay thanks
s
I guess technically speaking the JB guys would rather you use an if/else if for this kind of scenario but I still think it’s dumb lol
u
hh
I wont since I dont have ternary operator lol