Subject: Re: bug#68509: 30.0.50; pcase-dolist matches backquote pattern incorrectly

From: Ihor Radchenko <[email-masked]>
Date: Fri, 23 Feb 2024 14:05:19 +0000

Stefan Monnier <[email-masked]> writes:

>> May you then describe in more details what is the intended behavior when
>> PATTERN does not match VALUE in destructuring?
>
> How 'bout the patch below?
> ...
> +The precise behavior when the object does not actually match the pattern
> +depends on the types, although the body will not be silently skipped:
> +either an error is signaled or the body is run with some of the
> +variables bound to arbitrary values like @code{nil}.
> +For example, the above pattern will result in @var{x} and @var{y}
> +being extracted with operations like @code{car} or @code{nth}, so they
> +will get value @code{nil} when @var{my-list} is too short.  In contrast,
> +with a pattern like @code{`[add ,x ,y]}, those same variables would
> +be extracted using @code{aref} which would signal an error if
> +@var{my-list} is not an array or is too short.

This is confusing. In particular, "for example" implies that other
situations are possible. It is unclear how the reader will know when
"variables bound to arbitrary values" happen, when variables are bound
to nil, and when an error is signaled.

I would re-structure the paragraph, explicitly listing the possible
outcomes when the PATTERN does not match VALUE and stating that any
other non-matching PATTERN will lead to undefined outcome.

Also, with the current behavior of `pcase-let', it appears to be
impossible to distinguish between too short list (1 2 3) and
(1 2 3 nil nil) when assigning destructuring pattern.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>