bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#69108: false-positive warning "variable ‘_’ not left unused" in if-l


From: Eli Zaretskii
Subject: bug#69108: false-positive warning "variable ‘_’ not left unused" in if-let* and if-let
Date: Sun, 18 Feb 2024 08:53:37 +0200

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 69108@debbugs.gnu.org,  Hi-Angel@yandex.ru
> Date: Sat, 17 Feb 2024 23:02:07 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks, but can we please leave this as 'cond', instead of converting
> > it to a 'pcase'?  It doesn't seem to be justified here, and even less
> > so since you need to rewrite all the existing conditions.
> 
> Oh no.
> 
> If I don't rewrite this with `pcase', we would either artificially split
> this case:
> 
>   ((or `(,test) `(_ ,test))
>    (list (make-symbol "s") test))
> 
> into two separate `cond' branches, or we had to merge them into a one branch
> like this:
> 
>   ((or (null (cdr binding))
>        (eq '_ (car binding)))
>    (list (make-symbol "s")
>          (if (null (cdr binding))
>              (car binding)
>            (cadr binding))))
> 
> repeating a test.  Is this what you prefer?

Yes, I think so.  And you could perhaps avoid repetition of
(cdr binding) by saving the result of (null (cdr binding)) in
a local variable.

Or did I misunderstand the issues?

> Please to everyone: let's avoid a new discussion about `pcase'.  Please,
> not again.

It isn't a discussion.  I'm asking you (and everyone else) to avoid
using pcase where a simple cond will do, certainly when changing code
that already uses cond for most of the conditions.  That will both
decrease the code churn, and thus minimize the probability of
inadvertent mistakes, and make the code easier to read for some.

> > > [My doc tweaks]
> > This hunk seems to be unrelated?
> 
> Yes, I can make it a separate commit it drop it entirely if you prefer.

If it's unrelated, then yes, I'd prefer to separate it.

> > And it is not necessarily for the better, IMO, at least not all of it
> > (replaces active tense with passive, refills text that doesn't need
> > refilling, and other minor issues,
> 
> I can try to improve that of course.
> 
> > like the confusing use of construct state in "last ELSE form").
> 
> Dunno what a "construct state" is.

  https://en.wikipedia.org/wiki/Construct_state

It has to do with juxtaposition of several nouns to express genitive.
In this case I meant the replacement of "last form in ELSE" with "the
last ELSE form", which is more confusing, because it isn't clear
whether "last" refers to "ELSE" or to "form".

> The doc missed to tell what `if-let' returns when optional ELSE
> forms are omitted (which is allowed, and then there is no last ELSE
> form return value), so I tried to add that.  Did I mess up the
> grammar?

The grammar might be okay, but "last form in ELSE" is still better,
and your rewording lacks crucial punctuation which could have helped
interpreting the text correctly.  For example, there should be a comma
before "or nil if there are none".





reply via email to

[Prev in Thread] Current Thread [Next in Thread]