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.

[Ruckus]

That doesn't seem particularly useful. You know it has to be true after that, so there's no need for foo. Just say if (!doSomething()) return.

[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 { ... }

[Ruckus]

That's not the same thing at all

[df]

yeah sorry. the example sucks 😉

[df]

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

[Ruckus]

No need to apologize. I meant to say you're not really concerned with booleans. It looks to me like you're trying to find a concise way to guard against invalid data (in this case an empty list). There isn't really a way to do that as "valid" is a pretty domain specific concept.

[Ruckus]

You could do something like

repo.getPending().takeIf { !it.isEmpty() } ?: return

But I personally think the if check is more readable

[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

[Ruckus]

Indeed, both of those are better than my suggestion. I can only keep so much of std-lib in my head at one time 🙂

[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

[Ruckus]

@df If that's the case, you don't even need the return (unless there's more code after the forEach) as it won't do any iterations on an empty list.

[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 😉

[Ruckus]

Ah, I see. My condolences.

[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