From 1fb515e79f3d011213f8cc4ebe95d3c428624395 Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Tue, 3 Mar 2026 12:58:08 +0000 Subject: [PATCH] ; Suggest not using if-let* and friends to bind never-nil values. --- doc/lispref/control.texi | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/doc/lispref/control.texi b/doc/lispref/control.texi index e88a7533d89..95c436bdce0 100644 --- a/doc/lispref/control.texi +++ b/doc/lispref/control.texi @@ -376,6 +376,33 @@ Some Lisp programmers follow the convention that @code{and} and @code{when} and @code{when-let*} are for forms evaluated for side-effect with returned values ignored. +As a matter of style, it is best not to use these macros to bind values +that will always be non-@code{nil}. For example, suppose that +@code{foo-p} and @code{bar-p} might return @code{nil}, and the code +should not proceed in that case. Instead of + +@example +(when-let* ((foo-val (foo-p)) + (num (+ 2 foo-val)) + (bar-val (bar-p))) + ...) +@end example + +@noindent +consider using + +@example +(when-let* ((foo-val (foo-p))) + (let ((num (+ 2 foo-val)) + (when-let* ((bar-val (bar-p))) + ...))) +@end example + +@noindent +because this makes it clearer that the execution of the code is +conditional on @code{foo-val} and @code{bar-val} being non-@code{nil}, +but not directly conditional on @code{num}. + There is no @code{cond-let*} macro because extending the structure shared by @code{if-let*}, @code{when-let*} and @code{and-let*} to the case of @code{cond} is not simple.@footnote{The problem is that there