guard let is more powerfull - but maybe something like `val foo = bar?.also{ ... } ?: run { return@myfun }`matches more

There are apparently different use cases, and some of them looks cleaner in Kotlin, but some of them not very clean. Would be nice to see some real world examples. There is a big discussion about this somewhere on Kotlin issue tracker, and most examples from Swift there could be rewritten to Kotlin in a very clear way without

guard

One of the issues i have had is with nested objects for instance

if ( foo?.first?.second?.third?.fourth?.fifth != null ) {

}

in this case i will have to type that out if i want to use it in the block, of course i can create a property outside to store it but i just think this is much nicer.

if ( val foo1 = foo?.first?.second?.third?.fourth?.fifth ){
}

but I still agree, that probably we can find a set of good use cases and it will force Kotlin Team consider about guard or some other solution for them

Solution even without

if

.

val foo1 = foo?.first?.second?.third?.fourth?.fifth ?: return
foo1.doSomething()

Not really universal, but works for some cases

agreed but i might want to do multiple statements in an else clause as well.

yes, this is my point. Would cool to see some real code example, not imaginary

Because if you want to add such big feature to the language you need good real life examples where current syntax doesn’t work and a new syntax could significantly improve existing code

And yeah, if you want to have else, you can do this:

val foo1 = foo?.first?.second?.third?.fourth?.fifth
if (foo1 != null) {
   foo1.doSomething()
} else {
   otherStuff()
}

Yes, one line more, but still not sure that this much better:

if (val foo1 = foo?.first?.second?.third?.fourth?.fifth) {
foo1.doSomething()
} else {
otherStuff()
}

One line less and scoped foo1, not so bad.

But it's less easy to read/understand

but not sure that only this case enough to add new feature.

personally, a way of performing an

else

clause on the

.let {}

would suffice in my oppinion.

What would your

else

on a normal `.let{}`do?

let

is not nullability checking function and

else

for this case is really bad solution

let

is like

map

for single value + scoping

Also note that you can define your own thing if you want

its true that let is not meant for nullability checking but i personally think its the nicest way to perform a nullcheck

I reached a similar conclusion: http://beust.com/weblog/2016/01/14/a-close-look-at-kotlins-let/

same with forEach, a simple for loop is most of the time more readable

Which makes it annoying that InteliJ always recommend to change it over to

forEach

.

@gildor uploaded a file:

Really? Let me double check that.

You can disable this quickfix if you press alt-enter -> right arrow -> disable inspection

For me forEach looks better in most cases but actually I use collection operators much more often than

for

or pure

forEach

, and with collection operators like

list.filter().map{}

forEach looks better, because you just chain it

May I ask why you guys think for loop is more readable then

forEach

? IMO they are both readable, just in imperative aspect or functional aspect

Intuitively I expect loops to produce sideeffects and prefer to get that information from the left side of a statement.

I think the official style guide even suggests using for loops for when there is no nesting and the collection is not nullable

but truth be told its not (at least for me) a common situation where i end up using the foor loop

either the collection is nullable or i resolve the situation with collection operations

ahh, here -> https://kotlinlang.org/docs/reference/coding-conventions.html#using-loops

Imagine we have a builder chain like: “val b = Builder().addA().addB().addC().addD().build()“. I want to addD() only if certain condition is verified