In Rust, let-else patterns don't allow this, but match guards (used in `match` expressions and the `matches!` macro) can do something like this.

  while matches!(iterator.next(), Some((a, b)) if a + 1 == b) {
      println!("Hello!");
  }

However, using the bound values in an expression is a little harder.

  while match iterator.next() {
      Some((a, b)) if a + 1 == b => {
          println!("{a}, {b}");
          true
      },
      _ => false
  } {}

Since this is a well-formed transformation, it should theoretically be possible to implement this as a macro without changing the language.

The problem with patterns allowed to be expressions that simply evaluate to an object to be matched is that this gets in the way of doing potentially more useful things, like predicates, so it's kind of a waste:

TXR Lisp:

  1> (match (@a @(= (+ a 1))) '(1 3) a)
  ** match: (@a @(= (+ a 1))) failed to match object (1 3)
  1> (match (@a @(= (+ a 1))) '(1 2) a)
  1

An expression is treated as a predicate. The object being matched, like 2, is inserted as a right argument into it: (= (+ a 1) <obj>).

If you try the following, you get a surprising result:

  2> (match (@a @(+ a 1)) '(1 3) a)
  1

It is more verbose, but we can do more. We don't have to test for exact equality; e.g. @(< a) will match something that is greater than the previously matched a.

Capture a b that is greater than previously captured a:

  3> (match (@a @(< a @b)) '(1 3) (list a b))
  (1 3)

Or fail trying:

  4> (match (@a @(< a @b)) '(1 0) (list a b))
  ** match: (@a @(< a @b)) failed to match object (1 0)

We could treat certain functions differently; since + isn't a relational function producing a Boolean result, equality could be inserted implicitly to generate a predicate.

But, rather than that hack, there is a different one: user-defined patterns. We can have @(+ a 1) as a pattern by defining + as a pattern operator:

  1> (defmatch + (. args) ^@(= (+ ,*args)))
  +

Then:

  2> (match (@a @(+ a 1)) '(1 2) a)
  1
  3> (match (@a @(+ a 1)) '(1 3) a)
  ** match: (@a @(+ a 1)) failed to match object (1 3)

So I think what the author is suggesting is what was called “n+k patterns” in Haskell. I don’t recall the specific history, but over time there was a strong concensus that it was a bad idea. This might have been related to how signed integers work semantically, or some other gotcha

Why don't languages who need pattern matching use Unification? Turing-complete pattern matching, with known fast implementations. Why does everyone need to reinvent the wheel ad-hoc, and end up with a square wheel that only rolls on Tuesdays?

https://en.wikipedia.org/wiki/Unification_(computer_science)...

> Opens up blog post about pattern matching in Rust.

> Not a single "match" statement.

This post could increase its reach by explaining why a let statement is pattern matching, or at least point to a reference.

Although I understand people who don't know this already are not the target audience.

Here's the reference for those who need it: https://doc.rust-lang.org/book/ch18-01-all-the-places-for-pa...