Post

@romainguy.dev Does the first example allocate objects? It uses inline modifier which means the function will be inlined at the call site.

It's insane that the compiler produces the same for both of those. Practically magic

Agree but with a caveat. Kotlin needs a ternary operation. It's the only syntax I envy from other langs. "if-else" seems verbose to me given how succinct the rest of the language is. This was discussed ages ago and turned down (discuss.kotlinlang.org/t/ternary-op...) but I still want it damn it! 😂

Once you spend enough time looking at Java code in the IJ platform you realise that ternaries are an irresistible lure for unreadable code. I now fear ternaries. I've seen them nested three levels deep, with complex conditions and all the things they should never be paired with.

Maybe the compiler could not allow nested ternaries

I would love a ternary operator, just like I would love better bitwise operators. Both would make this nicer: ((((data[index + 0] and 0xf) shl 4) or if (index + 1 < data.size) (data[index + 1] and 0xf) else 0xf) and 0xff).toByte() (not production code :)

You are gonna love what I have done here tinyurl.com/36sahzay

How come that doesn't trigger a syntax error? Shouldn't that have been "invalid pwogwam dummy"?

The algo here just checks if the matching brackets or (nya,nyan) in this case are valid. I add an element to stack whenever an opening bracket is found and remove it when the closing bracket is found. This way the program will only throw error if the user program has mismatched brackets.

My own pet peeve is when folks use `?.let {} ?:` instead of if/else when checking null It's less readable, and more error prone (because if "doThing()" accidentally returns null, then you end up running the ?: branch, which often is not what you actually want.

I blame IntelliJ on this one. By default, it recommends the elvis in a bunch of cases 😐

The absence of the classic ternary operator in Kotlin is probably one of the reasons for this. One of the cases where Kotlin is more verbose than Java.

But the regular if else in Kotlin is shorter than takeIf/let

Funny, I saw the exact same example at a conference few months ago. Not everyone fall in the trap to overuse the “let”

Is this based on preference or just it being not readable? The second one is very clear, but the first look can be viewed as less code. I have no preference, though, but I would like to hear more.

The second one easier to grok

I feel some folks think that basic null checks are uncouth in idiomatic Kotlin. As a personal taste thing, I don't like 1 line if-else, but I'll put brackets in like your example all day long compared to adding an Elvis.

OMG I hate this. And people are like "this is idiomatic" kotlin. I used to link them to @jakewhartons tweet about it. But you should write a blog post about this so I can point people to it in code review when people tell me to use let. I already link them to your tweet regarding let, apply, etc

The one time I sometimes cave in and use .let for is for compose delegated mutableState which can not be safecast to not-null in a normal if check.