In Ruby case/in, how do the find pattern, | alternatives and if/unless guards work, and which of them may bind variables?

## Find patterns: searching inside an array An ordinary array pattern must match the whole array. A **find pattern** instead looks for a matching **run** of elements anywhere inside it: ```ruby case blocks in [*, {type: "mention", user:}, *] notify(user) end ``` - The leading and trailing splats are required and may be bare `*` or named (`*before`, `*after`), which then bind the elements on either side. - The middle can be several sub-patterns; they must match **consecutive** elements. - The first position where the middle fits is used. The reference's example: `["a", 1, "b", "c", 2]` matches `[*, String, String, *]` because `"b", "c"` are adjacent Strings. History: the find pattern was added as experimental in Ruby 3.0 and declared stable in 3.2. ## Alternatives: one of several shapes `|` combines patterns; the first alternative that matches wins: ```ruby in {type: "message" | "message_changed", text:} in Integer | Float in [:ok, _] | [:accepted, _] ``` The restriction is on **binding**. A capture inside an alternative is rejected by the parser with "variable capture in alternative pattern": ```ruby in {text:} | {body:} # SyntaxError ``` The reason is soundness: if the first alternative matched, `body` would be unset, and vice versa. The only exception is names beginning with an underscore, which signal a discarded value; the reference allows `in {a: _, b: _foo} | Array` but advises against reusing such values. Note that `{type: "message" | "message_changed", text:}` is fine: the alternative is only the value of `type`, and `text:` binds outside it. ## Guards: conditions after the pattern A guard is `if` or `unless` after an `in` pattern: ```ruby case event in {type: "message", ts: Integer => ts} if ts >= cutoff handle(event) in {type: "message"} :stale end ``` Mechanics: 1. The pattern is matched first and its variables are bound. 2. The guard expression is evaluated and may use those variables. 3. If the guard is falsy (or, with `unless`, truthy), the branch is skipped and matching continues with the next `in`. Guards appear **only on `case/in` branches**. The reference is explicit that `=>` and `in` cannot have a guard, and that `[1, 2] in a, b if b == a*2` is parsed as a standalone expression with a modifier `if`. ## Choosing between them | Need | Tool | Binds? | |---|---|---| | "Some element in this array looks like X" | find pattern `[*, X, *]` | yes | | "The value is one of these shapes/values" | alternative `A \| B` | only `_`-prefixed names | | "The shape fits and a condition on its parts holds" | guard `in P if cond` | variables from `P` are usable | | "Two parts are equal" | pin `^name` inside the pattern | yes | ## Traps to avoid - A catch-all such as `in _` or `in x` before more specific branches makes them unreachable. RuboCop's `Lint/UnreachablePatternBranch` (pending, added in 1.85) flags it, and it treats `in _ if cond` as not a catch-all because the guard may fail. - Repeated identical patterns across branches are flagged by `Lint/DuplicateMatchPattern` (pending). - An `in` branch with no body is flagged by `Lint/EmptyInPattern` (pending). - Guards that call expensive methods run for every candidate that reaches them; order branches so cheap structural checks filter first. ## Summary The find pattern searches, alternatives choose, and guards refine. Only the find pattern and ordinary sub-patterns bind freely; alternatives cannot capture (bar `_names`); guards can read what the pattern bound, but exist only on `case/in` branches.