procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

control.texi: Be a bit more explicit about the behavior of pcase-let

Browse source 
* doc/lispref/control.texi (Destructuring with pcase Patterns):
Clarify the kind of "unspecified" behavior that can occur when
the destructing pattern does not match the value.
This commit is contained in:
Stefan Monnier 2024-05-15 13:57:11 -04:00
parent 12988a359d
commit fea8d54c48
1 changed files with 12 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
doc/lispref/control.texi
View file

@ -1318,11 +1318,18 @@ example:
does the same as the previous example, except that it directly tries
to extract @code{x} and @code{y} from @code{my-list} without first
verifying if @code{my-list} is a list which has the right number of
elements and has @code{add} as its first element. The precise
behavior when the object does not actually match the pattern is
undefined, although the body will not be silently skipped: either an
error is signaled or the body is run with some of the variables
potentially bound to arbitrary values like @code{nil}.
elements and has @code{add} as its first element.
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.
The pcase patterns that are useful for destructuring bindings are
generally those described in @ref{Backquote Patterns}, since they