Subject: Re: bug#73853: Should and-let* become a synonym for when-let*?

From: Stefan Monnier <[email-masked]>
Date: Fri, 17 Jan 2025 21:31:45 -0500

Michael Heerdegen [2025-01-18 01:26:44] wrote:
> Stefan Monnier <[email-masked]> writes:
>> > Right.  The Lisp convention of using `when' for pure control flow and
>> > `and' for returning values is a good aid to readability.
>> AFAIK this convention is followed only by some coders, so it doesn't
>> help readability because you can't rely on it.
> This is a weak argument of its own.  You can't rely on any convention
> being honored in the code.  That doesn't mean that it's a bad convention.

My argument is not that it's a bad convention.  Instead I'm arguing
that the supposed benefit of this convention doesn't really apply because
it's not obeyed widely enough.

>> Then again, we don't have such a "value returning vs not" duplication
>> and associated convention for `let`, `progn`, `lambda`,
>> `unwind-protect`, `catch`, `condition-case, ...
>>
>> The fact we have all three of if/when/and is not a good justification
>> for `and-let*`.
>
> if/when/let are a bit different than the constructs in your list because
> the values in conditionals have different semantics when interpreted as
> a conditional than as an value or object.  This is part of the reason.

I don't see the "different semantics" you're alluding to, I'm afraid.
Can you explain what you mean?

> I can't imagine that changing (if (and-let ...) ...) to (if (when-let
> ...) ...)

[ FWIW, in all of Emacs and (Non)GNU ELPA, I could find
  only one "(if (and-let* ...) ...)", the one in `help.el`  ]

> is something that makes the language more attractive,

It wouldn't change anything to the readability of the code, AFAICT.
In both cases the preceding `if` makes it immediately clear that we're
interested in the final return value but only in whether it's nil
or not.

        Stefan