Conditional destructure `if { x } .= y` enters block when `y.x === undefined`

[STRd6]

if { x } .= y currently compiles to a key-presence test:

if (y && typeof y === 'object' && 'x' in y) {
  let { x } = y;
  ...
}

So if { x } .= { x: undefined } enters the block with x === undefined. switch y; when { x } uses the same semantics, intentionally — object pattern matching is shape-based.

In if context the key-presence test is surprising. The natural reading is "if I can pull a usable x out of y, do this," and undefined values silently passing the guard has caused at least one real bug.

Proposal

In if-form destructuring, require each bound name to be != null before entering:

if (y && typeof y === 'object' && y.x != null) {
  let { x } = y;
  ...
}

Rationale:

• != null (not full truthiness) preserves 0/""/false as legitimate values — same tradeoff if x := y already makes for the single-name case.
• Matches the intuitive read of "extract these values, only if they're set."

Open questions

1. Apply only to if-form, or also to switch when { x }? Diverging keeps switch as pure shape-match; aligning keeps the two siblings consistent.
2. Breaking change for any code relying on the current key-presence-with-undefined behavior — likely rare but worth scanning the codebase.
3. Nested patterns (if { a: { b } } .= y) — recurse the check, or only top-level?

[edemaine]

My main concern with this proposal is that it seems to deviate from the TypeScript meaning. I view if pattern := x as being similar to TS's x satisfies pattern. That's (to me) why object patterns are inexact, while arrays are exact length matching.

I'd thus view if { x } .= data as being a check whether data satisfies { x: unknown }, which { x: undefined } does. So I like the current behavior as the default.

That said, I think there's a need for checks like this (and checks on data content in general). I've definitely wanted this before. Maybe the issue is that we don't have a way to specify the right-hand side: TypeScript would say {x: string } or whatever, which excludes nulls.

0. For something specific like string, I've long dreamed of if { x: <? "string" } := y, i.e., generalizing the binary RHS to arbitrary properties, not just top-level.
1. We've discussed where/when clauses which most pattern-matching systems (e.g. Python) have. Some options:
   • if { x when x? } — condition on the inside of the object
   • if { x } when x? := y — condition on the outside of the object (looks a little weird)
   • if { x } := y when x? — condition on the outside of the entire pattern assignment
   • Optionally, I kind of want the flipped version of :=: if y =: { x } when x? or maybe if y =: { x } and x?
   • if ({ x } := y) and x? — might only work for if but pretty natural
   • if { x: &? } — more generally, any placeholder function means "check that this function returns truthy" (this is among my favorites)
2. Maybe what we need is Standard Schema integration? I've never used it myself but they're popular. For example:

   * as v from valibot
   if { name: ~v.string(), address: ~v.pipe v.string(), v.email() } := data

   ↓↓↓

   import * as v from 'valibot';
   if (typeof data === "object" && "name" in data && "address" in data && v.string().validate(data.name) && v.pipe(v.string(), v.email()).validate(data.address)) {
     const { name, address } = data;
   }

   ~ is one option — again this relates to how we should specify arbitrary conditions.
3. Perhaps something more general and not Standard Schema specific, where we can specify an arbitrary function, like name: |> v.string().validate or name: v.string().validate(.)...

Hmm, I actually realize that options 0 and 3 are related. Both <? "string" and |> v.string().validate are binary RHSs (roughly). For your original example, we could use |> &?. And maybe placeholder functions can have an implicit |> in front, so we could just write &?.

[bbrk24]

Somewhat tangentially, is typeof y === "object" the right check here? Or should we also allow it to be function?

[bbrk24]

0. For something specific like string, I've long dreamed of if { x: <? "string" } := y, i.e., generalizing the binary RHS to arbitrary properties, not just top-level.

Related: #753

[STRd6]

Somewhat tangentially, is typeof y === "object" the right check here? Or should we also allow it to be function?

We may want to allow it to be anything that can contain properties so maybe != null

[STRd6]

I like the concept of extending property checks to any binary RHS or placeholder partial.

Additionally when for additional conditions also seems handy.

Thoughts continue to simmer.