What do you prefer and why? :one: `nullableBoolean...

# announcements

[ribesg]

What do you prefer and why?
1️⃣ nullableBoolean == true
2️⃣ nullableBoolean ?: false

[louiscad]

Depends

[ribesg]

In my case I’m checking for nullableList?.contains(x) == true but I usually don’t really know which one to choose in any case

[iamthevoid]

you can create fun like this

fun Boolean?.safe() { return this ?: false }

But it applicable not everywhere

[louiscad]

== true is what the IDE often suggests, but historically, I used ?: false

[louiscad]

I don't like the naming of that extension function above.

[ribesg]

I have no warning in IDEA with both solutions and have intentions to go from of to the other in both directions… IDEA doesn’t seem to show a preference

[iamthevoid]

Maybe better fun like

fun Boolean?.safe(default: () -> Boolean) { return this ?: default() }

But it almost the same as elvis operator

[louiscad]

If you put such an expresstion in an if condition, I think the IDE will suggest == true @ribesg

[ribesg]

@iamthevoid this kinda hides the default value anyway and adds unneeded complexity

[ribesg]

@louiscad true

[Nir]

Here it obviously comes up in an "immediate" context so it's fine, but IMHO nullable booleans should not be allowed to linger. Believe it or not some people accept them as arguments into functions, etc.

[Nir]

It's kind of funny, when I looked at the two options in a vacuum, I prefer nullableBoolean == true , but when I look at your case involving a nullable list and ?. I prefer ?: false

[Nir]

So I think it just depends. someNullableObject?.memberFunc() ?: default is just a common pattern in Kotlin, generally, so I feel like it is applicable here

[elizarov]

https://kotlinlang.org/docs/coding-conventions.html#nullable-boolean-values-in-conditions

[ribesg]

This is my full real use case. No if condition

override fun hasSourcingRole() =
    authTokenService.getTokenRoles()?.contains("ROLE_SOURCING") == true

Maybe coding conventions could cover such case 🙂

[ribesg]

@Nir I agree it can be a code smell, but sometimes it can be useful. For example in my case I could let the null value pass as a “I don’t know” value, for example if I don’t know the user yet. Here an anonymous user doesn’t have the role, so returning a non-nullable boolean is ok, but I don’t feel like it should be a hard “`Boolean?` is bad” rule

[Nir]

@ribesg IMHO it's a pretty hard rule. If you want to do that, just have an enum with 3 levels, TRUE, FALSE, and UNKNOWN.

[ribesg]

Oh I hate the idea of an enum with values TRUE and FALSE so much

[Nir]

It's just making something that's potentially confusing, much more explicit

[Nir]

you can have a function that maps a nullable boolean to said enum of course, that way you just convert to the enum immediately when you get it, and pass it in that form

[ribesg]

Yeah but this kinda feels like java-is-far-too-much-verbose explicit to me

[Nir]

it's not really that much more explicit though, at the use site

[Nir]

if (foo == true)

vs
if (foo == Tribool.TRUE)

[Nir]

sorry, I meant "not that much more verbose"

[ribesg]

You mean if (foo). That’s so much more verbose, like triple the amount of letters 😛

[ribesg]

Actually I do have models with Boolean? in them and it’s perfectly fine for me. For example, we have something where the user can either accept or refuse to consent to something. We store that as a Boolean?, null means we didn’t ask yet. I have no problem with that

[ribesg]

Maybe I didn’t write any Java in 10 years and no longer fear null enough? 😄

[Nir]

if (foo) doesn't compile

[Nir]

It's not about fearing null, it's just about being explicit. The value could be missing for many different reasons, and later on as the application gets more complex you may suddenly find that it may not be filled out for 2 different reasons and you care which one

[Nir]

Either, for example, they didn't fill out the form where that question is asked yet, or they did fill it out, but chose to leave it blank

[Nir]

and now you have to change your nullable bool to an enum anyway, which is much more headache than adding another enumeration

[ribesg]

There is no possibility for the value to be missing in this case. null cannot mean anything else than “we never got an answer to that question”. I’m not writing forms like it’s the 90's, I’m mutating states and there is no mutator able to set this value to null

[Nir]

agree to disagree

[thanksforallthefish]

tbh in that case I would also go for an enum ACCEPTED, REFUSED, NOT_ASKED, then in real life I would probably opt for Boolean? 😛 laziness always wins (I always disliked tri-state boolean also when I was mostly coding java, but mostly because in java you never know when something is or is not nullable, in kotlin you do. that small ? makes all the difference in accepting nullable)

[azabost]

How about

fun Boolean?.orFalse() = this ?: false

similarly to the existing

@kotlin.internal.InlineOnly
public inline fun <T> List<T>?.orEmpty(): List<T> = this ?: emptyList()

[louiscad]

I like the naming of that one!