is there a special reason why kotlin has the elvis...

# announcements

[df]

is there a special reason why kotlin has the elvis operator for null values but nothing similar for booleans? A lot of times I'm doing sth. like

val foo = doSomething(); 
if (!foo) return;

and

val foo = doSomething() ?? return

would be nice.

[df]

i tried to make the example as simple as possible.. Imaging something like this

val items = repo.getPending()

if (items.isEmpty()) {
	return
}

items.forEach { ... }

[df]

yeah sorry. the example sucks 😉

[df]

and not only the example the whole question was not thought through, sorry

[Luke]

Doesn’t repo.getPending().ifEmpty { return } work?

[Tobias Berger]

@Ruckus that's almost exactly the line I was about to suggest (only I would replace !it.isEmpty() with it.isNotEmpty())
I personally prefer this to to the if check, but I guess that's just a style decision. Anyway, it combines a condition with the elvis operator

[Tobias Berger]

@Luke good idea, didn't think of that one. Good choice for Collections. the takeIf version can still be useful if you're checking a condition on something else.

[Nir]

Tbh if the objective is to validate data at multiple stages and early exit if it's not valid

[Nir]

Then could just use exceptions,. depending on use case

[Nir]

Will also allow you to bundle data about what exactly happened

[Tobias Berger]

Depending on the case that might make sense, but I think it's not the point of this question. You still have to get the check in there somehow, no matter if you want to return or throw something.

[df]

Didn't know about ifEmpty / ifNotEmpty.. pretty nice. And in my case it's not about validation. If there's nothing to do i simply want to return early.

[df]

but as said, ifEmpty { return } is pretty nice

[Nir]

I guess I was thinking in more complex use case cases, the "inner" function can simply throw. E.g. the original example with doSomething

[Nir]

youdon't need a check around doSomething if doSomething itself decides to throw

[df]

i know and again simplification. In this case I'd give a list of empty ids to some http client to request a list of records matching the given ids. Unfortunately the http client (3rd party code) is not smart enough to handle an empty list but instead does an http call and returns all records 😉

[df]

hehe

[xxfast]

I think this was brought up in kotlin keep presentation during kotlin 1.4 event - gist of it is that as far as language design goes - you don't want to confuse developers as to what the ? Stands for. In kotlin, question mark is always and exclusively for nullability notation

[Rob Elliot]

Which I really like… in groovy truthiness was nice 90% of the time and then a complete pain the other 10%

[df]

and it's something I really appreciate. I don't have a strong opinion on the operator, I was simply looking for a one liner to return early if false