Hey, quick question. When should we use the "it" keyword and when not? My google search on this was ...

# announcements

[silvio]

Hey, quick question. When should we use the "it" keyword and when not? My google search on this was a little bit inconclusive.

[LastExceed]

in the end it boils down to code style and readability. my rule of thumb is to use it when it's meaning becomes immediately obvious (usually in short lambdas such as .forEach { println(it) } ) and avoid it in nested situations (since name shadowing is almost never a good thing). otherwise decide case by case.

one could argue that for consistency you should just specify a name everywhere, but sometimes (especially in single-line scenarios) this will feel unnecessarily verbose

[silvio]

Alright, thanks! So it is not wrong to use it, because I read somewhere that there was discussion to remove it altogether, so I wasn't sure whether I can use it for small things like ResponseEntity.ok(it)

[LastExceed]

the example you just gave could be both good or bad depending on the size and context of the lambda that creates it

[silvio]

it's for flux when I receive a Flux<DTO> from the service I return dto.map { ResponseEntity.ok(it) }

[LastExceed]

oh so that was the whole content of the lambda. yeah this is the kind of situation the it keyword exists for

[David Eriksson]

@silvio: dto.map(ResponseEntity::ok)

[David Eriksson]

No it needed if the signature is compatible 🙂

[silvio]

i tried that, but thats not working for me

[silvio]

I'd have to give a type argument for the Response entity and when I do that the ok cannot be resolved

[David Eriksson]

Alright. But it is fine then.

[silvio]

But thanks anyways 🙂

[David Eriksson]

You could of course create a function "responseDto" with compatible signature