A modern programming language that makes developers happier.

kotlinlang

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

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 }```


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” :stuck_out_tongue_closed_eyes:).
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 :sweat_smile:

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! :smile: I understand this double confusion about the negated filter: they added very useful extensions in Kotlin, but maybe `filterNot` is more confusing that helpful.