forEach with elements as the receivers


#21

I guess one other point I’d make about my suggestion. Even if the internal implementations don’t use the existing tools, we should probably still use existing concepts, since we already have all the necessary concepts for receiver functions and iteration. I think that would still get us to about the same names I suggested.


#22

Considering that IntelliJ IDEA already adds a hint for multi-line receivers that implies this syntax, I believe this is the correct answer.

And since receivers are syntactic sugar to begin with, both an opt-in for non-receivers (i.e. this suggestion) and an opt-out for receivers (i.e. defining explicit variables to negate the receiver syntax and use regular lambda sequence) might be a good idea. Just seems weird to me to treat (T)->Unit and T.()->Unit as two entirely different things and having two of each method every time the user might prefer one syntax over the other.


#23

I did not expect this kind of success.

However this can be also a viable way to fix “Kotlin this overload”, where this become this + this@father + this@grandfather and so on.
This syntax can enforce this = it and requires explicit declaration of different this scope.


#24

I like this as well, but I like the following code as well:

list.withEach{ foo(key, value) }

(where list is List<Map.entree>)


#25

Has this been considered?

val iterable = listOf(...)
withEach(iterable) {
    // .. receivers accessible here
}