Something like headers.filterNot { it.first in noCopyHeaders }.toMap

Thanks, did not know about

.first

!

Minor, but - for

Map.Entry

it’ll be

.key

, not

.first

. The real improvement here is using

in

instead of

contains

, so I would combine Dominic’s and James’ answers to

headers.associate { it.toPair() }
   .filterKeys { it !in noCopyHeaders }

That's wonderful!

Cool solution Stav! I was wondering, how about filtering the list before instantiating the map?

headers.filterNot { it.key in noCopyHeaders }
       .associate { it.toPair() }

maybe a useless optimization, but could be useful on big datasets

I agree, since we’re going to call filter+associate either way, it’s probably better to filter first. On the matter of code style, I still prefer

.filter { it.key !in noCopyHeaders }

to

.filterNot { it.key in noCopyHeaders }

, just because it sounds more like English when read out loud, but that’s totally a matter of preference :)

Good point about filtering, yes. Oh I see your preference, yeah it’s a matter of preference, I liked to use this

filterNot()

since it’s available in Kotlin, but I can see maybe doesn’t read very well. On a side note, I remember there was some IntelliJ inspection warning to not negate your condition in an if/else to ease reasoning, what do you think?

In a lot of cases I would agree. e.g.

if (shouldKeep(item))

is better than

if (!shouldDiscard(item)

. But honestly I find that

filter

is already “confusing” because I have seen that for a lot of developers encountering

filter()

for the first time, they think about it as “should I filter (out) this item?“, rather than what it actually is, which is “should I keep this item?” So we have to “learn” that

filter

will KEEP anything I respond

true

to (and I personally have to repeat that to myself once in a while when trying to figure out what my predicate should return, but maybe I should already know this “intuitively” 😝). Anyway, that long rant about

filter

was to say that

filterNot

adds another layer of cognitive load (for me) where I have to think “ok, so filter keeps whatever I return true for, so filterNot will keep the falses”. Again, this is all a matter of preference, because if you naturally think of filter as “should I keep this item?” - then maybe

filterNot

makes more sense to you. To me it’s still confusing because now the question becomes “should I not keep this?“. How do you think about

filter

and

filterNot

? Maybe it’ll help me get more comfortable with it 😅

You’re absolutely right, I can relate because I still get confused by

filter

semantics, both in Java and Kotlin, and need to look up the docs at least once per session! 😄 I understand this double confusion about the negated filter: they added very useful extensions in Kotlin, but maybe

filterNot

is more confusing that helpful.