Feature #18773: deconstruct to receive a range

• Status: Assigned
• Priority: Normal
• Assignee: ktsj (Kazuki Tsujimoto)
• Target version: -

[kddeisz (Kevin Newton)]

Currently when you're pattern matching against a hash pattern, deconstruct_keys receives the keys that are being matched. This is really useful for computing expensive hashes.

However, when you're pattern matching against an array pattern, you don't receive any information. So if the array is expensive to compute (for instance loading an array of database records), you have no way to bail out. It would be useful to receive a range signifying how many records the pattern is specifying. It would be used like the following:

class ActiveRecord::Relation
  def deconstruct(range)
    (loaded? || range.cover?(count)) ? records : nil
  end
end

It needs to be a range and not just a number to handle cases where * is used. You would use it like:

case Person.all
in []
  "No records"
in [person]
  "Only #{person.name}"
else
  "Multiple people"
end

In this way, you wouldn't have to load the whole thing into memory to check if it pattern matched. The patch is here: https://github.com/ruby/ruby/pull/5905.

[kddeisz (Kevin Newton)]

• Description updated (diff)

[mame (Yusuke Endoh)]

• Assignee set to ktsj (Kazuki Tsujimoto)
• Status changed from Open to Assigned

[mame (Yusuke Endoh)]

It would be easier to discuss if you could write a spec of what pattern match will pass what range. I understand as follows by reading your implementation. Right?

• ary in [1, 2, 3] will call ary.deconstruct(3..3), which means "the length must be exactly 3"
• ary in [1, 2, *, 3] will call ary.deconstruct(3..), which means "the length must be greater than or equal to 3"

I understand your motivation, but I wonder if the spec could be more efficient. In the second calling sequence, the match requires only the first, second and last elements, but ary.deconstruct(3..) needs to create an array including all elements because it does not know which elements are required.

Though the current implementation of pattern matching is not so efficient, but I am afraid that the proposed implementation looks very inefficient because it creates a Method object and calls #arity.

[ktsj (Kazuki Tsujimoto)]

As a designer of pattern matching, I also understand your motivation.
However, I have the following concerns in addition to the ones mame pointed out.

• In the current implementation, when a pattern match fails in one-line pattern matching, the reason for the failure is displayed as an error message. I think it difficult to do the same thing by your proposal. (This feature is not a must, but it would be nice to have.)

$ ruby -e ‘[0] => []’
-e:1:in `<main>’: [0]: [0] length mismatch (given 1, expected 0) (NoMatchingPatternError)

• It might have a negative impact on performance. The current implementation caches the return value of deconstruct method, but this approach will no longer be available.