On 8/12/21 2:13 AM, Michael Heerdegen wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>>> But Michael points out that it seems your code won't perform the
>>> assignment if the pattern doesn't match, which I find to be an
>>> odd behavior.
>
> I hope that this is even true in all cases.
>
>>> I'd expect a behavior like that of `pcase-let`, instead.
>>
>> ... because I have no opinion here, really -- behaving like `pcase-let'
>> would be good, but on the other hand, the current behaviour also kinda
>> sorta makes sense.
>
> Here is something else that is odd:
>
> (let ((a 17)
>        (b 17)
>        (x 17))
>    (pcase-setq (or `((,a) [(,b)])
>                    x)
>                '((1) [(2)]))
>    (list a b x)) ;; ==> (1 2 nil)
>
> The first `or' branch matches, nevertheless is the binding of `x' being
> set to (a totally unrelated value) nil which doesn't make much sense.
>
>
> Michael.
>


I think that the behavior makes sense for a pattern-matching `let` and
maybe not so much for a destructuring `setq`, which was my intended use
case. I think that it is different because the effects of the
`pcase-setq` form could be less temporary than the effects of the
`pcase-let` form.

If thought of as a destructuring `setq`, then I see the value in
signaling an error when a pattern doesn't match, as you said, but I
guess that would be inconsistent with the value assignments that `or`
generates.

I've attached an example version that would set all of the named
variables to nil before assigning values from the pattern, but I feel
like it is not the best behavior.  Please correct my understanding if
that is not what was meant by "a behavior like that of `pcase-let`".