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

From: Jonas Bernoulli <[email-masked]>
Date: Tue, 29 Oct 2024 16:21:57 +0100

Hello all,

It is very disappointing that you have chosen to deprecate if-let and
when-let in such a rushed manner.  The same was done and reverted in
2018, and many of the same actors are involved this time around.
I am surprised that you would make the same unforced error again.

Reading through this and past conversations it is clear that there is no
consensus what the ultimate goal is.  But as far as I can tell, few, if
any, are fully satisfied with the current (30.0.*) situation.  There
also seems to be agreement that unfortunate mistakes were made in the
past, which limits our options now.

This could have been prevented if more people (including non-debbugs and
non-emacs-devel regulars) were given a chance to think about the problem
and time to articulate their concerns and proposals, before facts were
created.  Or even if the people who did take part in past conversations
had spend more time actually talking things through.

The same could have been done every time the dissatisfying state of the
foo-let forms was brought up again, but instead new facts were rushed at
every turn.

Without stopping this destructive pattern, you won't be able to fix this
mess.

My short-term proposal is this:

- Revert the depredations and remove the news entry.

  Even if you later decide to go through with the deprecation after
  all, the "damage" done by doing, reverting and redoing a few lines is
  minimal.  (Even so, maybe discuss it for a few days before reverting.)

  This would have the benefit of not needlessly alienating those package
  authors who currently use foo-let and would like to keep doing so, if
  the ultimate decision is to not go through with the deprecation after
  all.

- Do NOT revert the changes from using foo-let to using foo-let* in
  Emacs itself.

  You might end up deciding to go through with the deprecation after
  all, in which case it would be unfortunate to switch thousands of
  lines back and forth.

- Re-read past conversations.

  Think about what *your* ideal solutions would be (think big here).
  Think about what your best *feasible* solutions would be.  Think about
  what compromises you would be willing to make.  Think about what
  compromises you would *not* willing to make, and articulate why.

  Think about what others have said, and what compromises they would
  have to make to satisfy your position and those of others.  Try to
  understand where they are coming from.  You do not have to *agree*
  with their motivations, to appreciate how severe the concessions are,
  they would have to make to *them*, to agree to your idea of the
  best feasible solution and your idea of an acceptable compromise.

  Think in particular about whether achieving your goal/compromise,
  would require them to roll over and admit defeat.  Consider whether
  sticking to the current (30.0.*) status quo, might after all be the
  best *compromise* we could possibly reach.

- Do not have this conversation just among yourselves.  Any change
  you make here is going to affect *many* packages and their authors and
  users.  Actively involve the affected community.  Reach out on several
  channels, and give people time to think about the problem and share
  their thoughts.  I am talking months here, not weeks or even days.

- In addition to thinking about the state you want to reach eventually,
  also think about the transition process.  Should it be done in several
  steps, and if so, what would the consequences for package authors be?
  Could it be done in a way that does not force package authors to
  change their code multiple times?  Could a variable similar in spirit
  to lexical-binding be a viable option?

- If you think that this proposal is over the top, try to consider it
  from the perspective of the maintainers of external packages.  Take
  the history of this whole saga into account.  Realize that there are
  people who have been burned by this before and who will be upset if
  being forced to change their packages again, maybe in a way they see
  as a step backward.  Even if you decide that those who disagree with
  you are simply wrong and/or lack good taste, consider whether it is
  worth alienating people over this.

To help kick start an informed decision finding process I have searched
the Emacsmirror (a superset of GNU ELPA + NonGNU ELPA + MELPA) for these
forms:

| grep pattern        | hits |
|---------------------+------|
| "(if-let\( \|$\)"   | 1853 |
| "(if-let\*"         |  422 |
| "(when-let\( \|$\)" | 4260 |
| "(when-let\*"       | 1162 |
| "(and-let\*"        |  288 |

Best regards,
Jonas