Status

TL;DR The current release of this library is a beta release. Breaking changes are unlikely, but I cannot rule them out completely.

IMO the biggest issue with the built-in implementations of the forms also provided by this library, is not so much that mistakes were made, but that they were not eventually fully fixed. Doing so would have required breaking changes and it is understandable that this was not done – after all many packages use these forms, and backward compatibility is important.

Unfortunately this also led to an increasingly inconsistent interface, and despite the effort to maintain backward compatibility, downstreams had to deal with deprecations. Since we had to revisit many uses of these forms anyway, I personally would have preferred to get something out of it, i.e., if some backward compatibility had been sacrificed, for the sake of getting a more consistend, complete and pleasant implementation. But again, I understand why that wasn’t done.

Since this is a new implementation (which can happily co-exist with the built-in implementation, so nobody has to upgrade), I do have the opportunity to do it differently.

For starters, having used the built-in implementations for many years, I had the opportunity to learn from past mistakes and can thus avoid repeating them. It also helps, that I think that these forms are awesome (as opposed to something that can be useful once in a blue moon, or worse even something that I personally avoid, but which I am forced to maintain because other people want to use it).

So I had/have both the desire and opportunity to provide the best implementation, I can come up with. Of course, that doesn’t mean that I am safe from making any mistakes, or that my opinion on what the optimal behavior is, cannot possibly evolve over time.

I have now used this successfully for several months in many of my packages, including Magit, Transient and Forge. There were no bugs or breaking changes. (Okay okay, there was one typo in a debug declaration.) I am still happy with what I have come up with. I’ve added one additional form, when$, which was missing from the initial alpha release.

However, nobody else is using this so far, so I haven’t yet gotten any feedback. Once others use this, they might make a brilliant suggestion, which requires a breaking change. I do not expect this to happen, but in case it does, I intend to make such changes. I would announce such a change here, ahead of time, so you should probably subscribe.

To reduce the risk of breaking changes, I implemented some things defensively. For example, I am unsure whether and-let should take a single BODYFORM or a multiple BODY forms, and if the latter, whether that should behave as if it were wrapped with and or with progn. I went with a single BODYFORM, because that keeps the door open to switch to either of the two alternatives, without that being a breaking change.