Re: if-let/if-let*/and-let/..

[Michael Heerdegen]

Eli Zaretskii <address@hidden> writes:

> That foo-let did support that case doesn't necessarily mean it has to
> support that in the future, nor that we must make that
> backward-incompatible immediately.  We could simply let foo-let be as
> it is today on the release branch and collect more experience before
> we make our decision.  Does that make sense?

This isn't about experience: the old single binding syntax is simply
obsolete:

(1)   (if-let (a (calculate-a))   use-a ...)

is the same as

(2)   (if-let ((a (calculate-a))) use-a ...)

The problem is that people still use the syntax (1) in code a lot (since
it was once the only valid syntax AFAICT), and `if-let*' interprets a
varlist as in (1) in a _different way_.  That's why we decided to
obsolete if-let.  That gave us the compiler warning problem which
annoyed many people.

We are now going in circles in the discussions for a while.  There
simply is no optimal solution to that problem.  We have to decide what
we want, more time won't help.  Keeping both names foo-let and foo-let*
with very small, illogical semantic differences as we have now would be
the worst solution, as Stefan pointed out.

My suggested solution (the solution of the commit I had installed and
then reverted) was to change `if-let*' for the special case so that it
also supports the old interpretation of a varlist as in (1).  Then we
can make `foo-let' and `foo-let*' synonyms, which is what we want, and
also a quite harmless change, since the names `foo-let*' are new in 26.1
and I have checked every individual occurrence of a foo-let* varlist of
kind (1) in the Emacs sources and in Gnu Elpa.

There are other solutions, of course.  I would rather get rid of the old
semantic, but that's not possible without creating a large amount of
annoyance for a longer time.


Michael.