Add Enumerable#pick

[eugeneius]

As with pluck (#20339), it's useful to be able to call pick on loaded relations, unloaded relations, and plain enumerables interchangeably.

This also ensures that it's always safe to rewrite pluck(:title).first as pick(:title).

[simi]

Looks ok to me since it follows same pattern as pluck and there's probably no chance to get this to Ruby itself, since it is not useful for Enumerable in general.

👍

[kaspth]

Should we normalize to return an empty array like pluck does? Could potentially tap compact! at the end of the map.

[eugeneius]

I don't think we can use compact, since we need to keep any nil values that were picked when the enumerable isn't empty. We could add a special case for when it is empty, though.

Using the rubric that pick(...) should be equivalent to pluck(...).first, picking an empty enumerable seems like it should return nil:

irb(main):001:0> [].pluck(:dollar, :cents).first
=> nil

This is how Relation#pick already behaves:

rails/activerecord/test/cases/calculations_test.rb

Line 917 in f265e0d

assert_nil Topic.none.pick(:author_name, :author_email_address)

I have a slight preference for aligning with that existing behaviour, although in practice I think the result of calling pick with multiple arguments is usually destructured, so it doesn't matter too much which behaviour we pick choose:

irb(main):001:0> a, b = nil; [a, b]
=> [nil, nil]
irb(main):002:0> a, b = []; [a, b]
=> [nil, nil]
irb(main):003:0> a, b = [nil, nil]; [a, b]
=> [nil, nil]

[kaspth]

My objection was more to seeing [] for the pluck return versus [ nil, nil ] for pick, size would be different or similar.

I have a slight preference for aligning with that existing behaviour,

Same, but the nil is the default return for a method call, so it would do that regardless. I like the none? fix.

[kaspth]

These ain't slim pickings, bud! Thanks for adding this, @eugeneius ✌️