From: "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>
Date: 2025-10-16T02:53:04+00:00
Subject: [ruby-core:123488] [Ruby Feature#21615] Introduce `Array#values`

Issue #21615 has been updated by mame (Yusuke Endoh).


This feels like opening Pandora's box. If this is accepted, I can foresee the following discussions arising, just off the top of my head:

* Should `Array#keys` be defined as a method that returns `(0...ary.size).to_a`?
* `Array#find_index` and `Hash#key` are (roughly) counterparts. Should they be aliased to each other?
* Should `Hash#each_key` and `Array#each_index` also be aliased to each other?
* What about order-related operations? Wouldn't we also need methods like `Hash#reverse`, `Hash#rotate`, and `Hash#sort`? (Note that `Hash#sort` would be incompatible with `Enumerable#sort`).
* Should methods like `Array#rehash` and `Array#compare_by_identity` be provided (perhaps as no-ops)?
* Wouldn't `Array#default` and `Array#default=` also be necessary?
* Should operators like `Array#<=` be defined to align with `Hash#<=`?
* While `Array#transform_values` could be defined straightforwardly, how should `Array#transform_keys` behave?
* The different meanings of `Array#include?` and `Hash#include?` are surprising.
* The different meanings of `Array#assoc` and `Hash#assoc` are surprising.

After all, I personally feel that `Array` and `Hash` are not inherently polymorphic.
If you want to use them polymorphically, I think you should limit their polymorphic use to `#[]` only.

----------------------------------------
Feature #21615: Introduce `Array#values`
https://bugs.ruby-lang.org/issues/21615#change-114861

* Author: matheusrich (Matheus Richard)
* Status: Open
----------------------------------------
## Motivation

In Ruby code, it's common to accept arrays and hashes and treat them uniformly as collections of values. `Hash` exposes `#values`, but `Array` does not, which pushes developers toward `is_a?`/`respond_to?` branching.

Following the **Principle of Least Surprise**, users may reasonably expect `Array#values` to exist because:

* Both `Array` **and** `Hash` already implement `#values_at`.
* `Hash` implements `#values` but `Array` does not.

### Example

Today:

```ruby
def normalize_records(input)
  items = input.respond_to?(:values) ? input.values : input

  items.each do |item|
    do_stuff_with_item(item)
  end
end
```

With `Array#values`:

```ruby
def normalize_records(input)
  input.values.each do |item|
    do_stuff_with_item(item)
  end
end
```

## Proposal

Add `Array#values`, returning a copy of the elements of `self`.

This yields a uniform interface for `Array` and `Hash` values without type checks.

### Alternatives considered

* `Enumerable#values`: defaulting to `to_a`, but I found it too broad of a change.
* `Array#each_value`: redundant as `Array#each` already covers iteration.


Patch: https://github.com/ruby/ruby/pull/14641



-- 
https://bugs.ruby-lang.org/
______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/