Will "It" variable stay or go?

21

This is very easy to understand, this even removes the necessity of looking at previous code to understand. It is similar to java filter

22

OffTopic: What is even harder to understand for me is why I see this post as last commented on an hour ago, while the last reply is yours and is timestamped 5th of Jan - 237 days ago according to the forum.

Deleted comments usually remain visible as “Deleted - reference will be removed in X time”.

Forum bug???

NB: This comment itself was labelled with the date 6 of Jan before I edited it, while we’re writing August 31.
Comments made today on other threads, do have the right date. And the date on this comment seems to have fixed itself after editing.

23

This is my only concern about it , seems to vague and you could easily get lost if you are accessing not very descriptive attributes like it.id .

Not sure if its possible but it could be replaced with a word which is the Type of it but in lowercase to make it explicit.

listOfDogs.map{ dog.age + 1 } // Assuming List<Dog>
listOfCats.map{ cat.evil * 1000 } // Asuming List<Cat>

it is definitely not idiomatic.

24

I do find it idiomatic. And it is here to stay, given it has made it this far.

Your ‘lower case type’ could be an addition, but not a replacement. It is here to stay, and for many it is good thing once you get used to it.

Think of your example
 the ‘dog’
how old is it?

I actually also like your idea, but hard to retrospectively introduce is a problem as there is the risk the type name is already in scope in the lower case. val dog= Dog(“Fido”) is a common construct.

25

Implicitly creating variables with names derived from types (which usually aren’t visible in the code) using a non-trivial transformation is anything but explicit. If you find yourself getting lost in expressions like “it.id”, simply create an explicit variable instead of it.

4 Likes
27

I had a similar problem, that’s probably why this thread is still alive.
I’m so sorry for posting without looking at the timestamp, but the kotlin discussion email highlighted this thread for me and I assumed it was new.
Is there any way to close a thread or mark it as “mostly solved”? :thinking:

28

Scala has the exact same functionality, and I have yet to see any issue with it.

Scala:

val range:List[Int] = (0 to 10).map(_ * 2)

val tuples:List[(Int, Int)] = List( (1,2), (2,3) )
tuples.map(_._2 * 2)

Kotlin

val range = (0..10).map{it * 3}

In Scala, the _ is never usable outside of the first declaration. So you can’t do something like this

tuples.map(_._1 * _._2)

or even

tuples.map(if(_){
    ......
})

Which keeps people from making a syntactic mess of things.
I think this should be the non-enforced rule for Kotlin as well. If you’re going to use the reference multiple times, name it.

29

You can always write code like this.

class Tree(val data: String, children: List<Tree>)


tree.forEach {
  if (it.data != "special") {
    it.children.filter {
      it.data == "special" // it's NOT the same "it.data" as two lines above, but nothing suggests that in the syntax
    }
  }
}

It for single parameter lambdas is very useful, in fact, I would take it even further, make it work for loops like this.

val list = listOf(...)

for (list) println(it) 
for (1..10) println(it)

In the cases where it becomes ambiguous, it is the job of the programmer to specify the name of the argument. My hope is that you don’t remove a very useful feature just because some people are not able to handle it properly, it saves me a lot of redundant typing and I personally love it.

1 Like