Michael Böiers
04/30/2021, 12:46 PMif (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()) { … }
Stephan Schroeder
04/30/2021, 12:53 PMnull
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.)christophsturm
04/30/2021, 12:54 PMif (!foo.isNullOrEmpty()) {}
Michael Böiers
04/30/2021, 12:57 PMchristophsturm
04/30/2021, 12:57 PMMichael Böiers
04/30/2021, 12:58 PMchristophsturm
04/30/2021, 1:01 PMMichael Böiers
04/30/2021, 1:09 PMRoukanken
04/30/2021, 1:20 PMfalse 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).if(foo != null && foo.isNotEmpty())
might be more readable than default value. Ofc, only works on local variables/args...Michael Böiers
04/30/2021, 1:25 PMRoukanken
04/30/2021, 1:25 PMMichael Böiers
04/30/2021, 1:26 PMCharSequence?.isNeitherNullNorEmpty()
would be nice - it’s verbose, but it seems to be the Kotlin way.Roukanken
04/30/2021, 1:29 PMNir
04/30/2021, 1:31 PMRoukanken
04/30/2021, 1:32 PM@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 worksMichael Böiers
04/30/2021, 1:33 PMNir
04/30/2021, 1:33 PMRoukanken
04/30/2021, 1:33 PMNir
04/30/2021, 1:33 PMMichael Böiers
04/30/2021, 1:35 PMilya.gorbunov
04/30/2021, 2:05 PM.isTrue()
significantly better than == true
?ephemient
04/30/2021, 2:09 PM== true
over ?: false
Nir
04/30/2021, 2:09 PMchristophsturm
04/30/2021, 2:10 PM== true
is a noop but thats only true for non nullable booleansNir
04/30/2021, 2:11 PMRoukanken
04/30/2021, 2:12 PM?:
or ==
it's whatever, but it should be explicitNir
04/30/2021, 2:14 PM== true
is not terribly explicit to meif (<expression>)
and if (<expression> == true)
I'd expect them to be the sameephemient
04/30/2021, 2:15 PM== true
or != false
the right choice? they have different behavior on nullokarm
04/30/2021, 2:15 PMNir
04/30/2021, 2:15 PMif
already does thattrue
ephemient
04/30/2021, 2:16 PMNir
04/30/2021, 2:17 PMif
broader== True
(or maybe you can but they return False)== true
ephemient
04/30/2021, 2:18 PM== true
in C, Perl, Python, Ruby, JS etc. changes what an if
will doRoukanken
04/30/2021, 2:18 PMephemient
04/30/2021, 2:18 PMNir
04/30/2021, 2:19 PMephemient
04/30/2021, 2:19 PMNir
04/30/2021, 2:19 PMRoukanken
04/30/2021, 2:20 PMephemient
04/30/2021, 2:20 PMNir
04/30/2021, 2:20 PMephemient
04/30/2021, 2:20 PMNir
04/30/2021, 2:20 PMokarm
04/30/2021, 2:27 PMif(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.Nir
04/30/2021, 2:27 PMtrue
okarm
04/30/2021, 2:31 PMtrue
- but please forget about the special treatment of primitive boolean. It's been lifted, promoted to a 3-way value. In that sense it's no different from any other equals
comparison.Michael Böiers
04/30/2021, 2:35 PMNir
04/30/2021, 2:46 PMokarm
04/30/2021, 2:47 PMI 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 booleanThis
Nir
04/30/2021, 2:47 PMMichael Böiers
05/01/2021, 9:27 PM