Re: Replace trivial pcase occurrences in the Emacs sources

[Clément Pit-Claudel]

On 30/10/2018 20.08, Andy Moreton wrote:
> On Tue 30 Oct 2018, Clément Pit-Claudel wrote:
> 
>> On 30/10/2018 14.14, Alan Mackenzie wrote:
>>> Hello, Clément.
>>
>> Hey Alan :)
>>
>>> On Tue, Oct 30, 2018 at 11:05:55 -0400, Clément Pit-Claudel wrote:
>>>> On 30/10/2018 10.16, Andy Moreton wrote:
>>>>> How are users meant to write reliable code using such constructs ?
>>>
>>>> Ensure that the pattern actually matches :)
>>>
>>> You mean, unless you can be 100% sure that the pattern will match, you
>>> mustn't use pcase-... constructs.  That sounds equivalent to saying you
>>> shouldn't use these constructs at all.
>>
>> That's an odd conclusion.
> 
> It is a perfectly reasonable conclusion. 

Why?  A large number of ELisp functions don't say what they do if their 
argument isn't of the expected type, or doesn't have the expected structure.  
If you're not 100% sure that the argument has the right type, you shouldn't use 
them (instead, you should do an appropriate check first).  This is not 
equivalent to saying that they shouldn't be used at all.

I don't understand what's so special about pcase-*.  Functions like lookup-key 
or define-key don't tell you what happens if you pass something else that a 
keymap; does that mean you should never use them? Same for a function like 
`c-common-init' in cc-mode (the doc doesn't tell you what happens if you pass a 
symbol that isn't a mode; AFAICT, if you do, you get an error but the current 
buffer is left in a broken state.

This is a pattern across most ELisp functions, really: if you pass them the 
wrong thing, some do sanity checks and exit cleanly, some exit silently, some 
raise a seemingly unrelated error, etc. Most of them don't document that 
behavior (some, like car and cdr, do).

If pcase-dolist, pcase-let, or pcase-lambda happen across a value that doesn't 
match the pattern, they'll typically raise an error; that behavior isn't 
guaranteed, so you're not supposed to rely on it. The docs point it out. We can 
debate whether they should be amended to have more predictable behavior in the 
face of match failures, but it's sounds like a real stretch to conclude that 
they shouldn't be used at all use them at all.

Clément.