I find it more concise to read

if (flag1 && (flag2 || someFlag.orTrue()))

rather than

if (flag1 && (flag2 || someFlag ?: true))

, perhaps it's a personal preference 🙂

oh

double-check priority of

?:

in such cases

yep, also that...

false.orTrue()

wouldn't make sense, because

orTrue()

is defined mainly to handle nullable booleans...

in my case coming from parsing json

fun <T:Any> T?.default(value: T)

then?:)

and then it's just the same elvis operator but with clear priority

yes, a nice variant too. I just modeled after exisiting

List.orEmpty()

,

String.orEmpty()

...

I like

?.

-chains but have to augment them a lot to include stuff

>=

,

x+this

etc

Is there such as thing as

HashMap.putIf()

? A generalization of

putIfAbsent

where the condition can be passed as a closure instead of just being

get() == null

?

Maybe compute()

@jdiaz Yes that would work. Surprised to see this is on Java’s

HashMap

actually 🙂

Imo java has a lot of things written in a really verbose way

The Kotlin version is a bit awkward because of the absence of SAM conversion but not unexpected:

val m = hashMapOf<String, String>()
    val f = BiFunction { k: String, v: String? ->
        if (v == null) "defaultString" else v + " added string"
    }
    m.compute("foo", f)

absence of SAM conversion ?

I wish I didn’t have to do

BiFunction {}

Old beef of mine 🙂

Oh wait I can remove it actually

m.compute("foo") { k: String, v: String? ->
        if (v == null) "defaultString" else v + " added string"
    }

I could have sworn this didn’t used to compile

that why I asked

mmmmm... old beef

maybe you're thinking of the issue where you can't mix SAM conversions with regular types @cedric? https://youtrack.jetbrains.com/issue/KT-13609

@damian Yes

@dimsuz You can also use explicit comparison of Boolean:

if (flag1 && (flag2 || someFlag == true))

More clean and native then elvis or extension function

Hi, I have an issue with kotlin. When I write a for loop on a collection (not an array) using indices and getting the value manually after that to avoid Iterator allocation, the IDE (Android Studio) suggests me to use the stdlib idiom instead, which allocates a hidden iterator. This is not acceptable for operations that happen on the UI thread in Android, especially when in onDraw methods that are called at 60Hz in front of the user. Please, could you add a way to make kotlin use the index version (and not the iterator version) under the hood when iterating over collections? I'd see it with different methods with either a different name or an additional parameter to specify to use index instead of iterator, or an annotation on the statement, or a compiler flag similar to the one that makes all classes open.

Is there any reason you're not comfortable suppressing that warning or just turning the inspection off?

Yeah I kinda wish there was a cleaner way, like withIndex but without the iterator.

If another developer encounters the warning, because this inspection is on by default, he may think the recommended syntax is better, and may not know about the far from obvious side effects. Then the UI would start to lag it this was called on UI thread

Please, note that I'd love using the recommended, cleaner syntax if I could make sure it doesn't allocate anything when I just ask him for iteration