I’m wondering why the if statement doesn’t expect a nullable Boolean type. What would be the disadvantage of allowing it? Consider this:

if (foo?.isNotEmpty() ?: false) { … }

That works, but it’s not really concise. Wouldn’t it be better (and safe) if we could just write

if (foo?.isNotEmpty()) { … }

how is autocasting

null

to

false

safer and better? (and if you have an answer, you won't find many (relatively spoken) who aggree with you in this chat.)

in your example:

if (!foo.isNullOrEmpty()) {}

@christophsturm Yes, that works well for Strings, but not so much for generic conditions. I suppose I could always write my own extension function to hide away the elvis operator. 🙂

in the end you don’t want to arrive in a situation where a flag is either null or false or true.

That’s where I am sometimes. The best solution is of course to avoid the nullable type in the first place.

i think one of the most common usecases are optional strings and there isNullOrEmpty helps.

Ok, it was a bad idea. Blame it on Friday! 🙂

optional booleans are almost never a good idea non-optional booleans with default value replace them in 90% of cases at least and if someone says "But I need 3 diff values!" then it's not a fucking boolean then! Get an enum or your some of own class instead. Sadly I see this often in production code, with comments like

false means A happened, true means B happened, null means OK

Anyways, enum or replacing with default value at earliest possibility / handling it somehow else (example sometimes return from function can be a solution).

Yes, that’s kind of the “java way” of doing it. Works well for short variable names, otherwise the expression gets kind of lengthy. In that case I’d rather go elvis 🙂

yeah, it depends on the expresion, that's why "sometimes"

Now I’m wondering why the isNotEmpty function doesn’t accept a null receiver. I guess it’s because these things are meant to be made explicit in Kotlin

(that's what contracts are for no?)

You could have an extension for booleans themselves

@OptIn(ExperimentalContracts::class)
fun CharSequence?.isNotNullOrEmpty(): Boolean {
    contract { 
        returns(true) implies (this@isNotNullOrEmpty != null)
    }
    
    return this != null && this.isNotEmpty()
}

fun bar(foo: String?) =
    if (foo.isNotNullOrEmpty()) foo + "bar" else null

this works

Haven’t looked into contracts yet … interesting!

Then you could write foo?.isBar().isTrue()

anyways, smth like that should work, I'm not too knowledgable of them either 😛

Or if you want to be more explicit, isTrueAndNotNull

Contract works in this case, but it’s experimental …

Is

.isTrue()

significantly better than

== true

?

yeah I was going to say, I thought Kotlin style was

== true

over

?: false

Ah right, I actually forgot that == works on nullables

nice! i always thought

== true

is a noop but thats only true for non nullable booleans

I think, to be honest, you could make an argument that if something works with == true, it should just work directly as the condition

yes you could, but I still think you should get kicked in face by your IDE, "Care this is nullable!" and whenever to handle it with

?:

or

==

it's whatever, but it should be explicit

I dunno,

== true

is not terribly explicit to me

is

== true

or

!= false

the right choice? they have different behavior on null

It is explicit (when compared to ?: false), because you're explicitly specifying the value you are interested in.

but

if

already does that

is it?

truthiness would make the range of acceptable things in

if

broader

== true

in C, Perl, Python, Ruby, JS etc. changes what an

if

will do

(that's true here too, tho)

it doesn't in Java and Kotlin, because they require a strict boolean

It does, because == true can make something compile

not compiling doesn't change behavior, there was none before

different definitions of change behavior

imho, going from "no behavior" to "some" is a change

do I need to explicitly say, changes runtime behavior?

Do I need to say, explicitly changes program behavior?

what else matters

etc, this is poitnless

That's like saying "It's unusual

if(Char)

doesn't compile but `if(Char == 'a')`", no? With nullable Boolean you're no longer dealing with "standard bool", but you're comparing two values that might as well be random.

It's not like that example at all, no, because the value on the right is not

true

But with null in the mix "the value on the right is not `true`" no longer makes sense

@Nir consider that == is different from === in Kotlin.

@okarm I'm not sure what you mean by that

I guess what it boils down to, which is pretty unique to languages with null baked into the type system, is that there's a type above boolean

This

yep

@Nir No, it’s not. Nevermind. 🙂