Re: Mysteries of unwind-protect

> On 15 Jan 2026, at 13:47, Tim Bradshaw (as tfb at tfeb dot org) <[email protected]> wrote:
> 
> (defun ts ()
>  (declare (optimize speed))
>  #+LispWorks
>  (declare (optimize (float 0))
>           (:explain :boxing))
>  (let ((v (make-array 1 :element-type 'double-float :initial-element 0.0d0)))
>    (declare (type (simple-array double-float (1)) v))
>    (let ((v0 (aref v 0)))
>      (declare (type double-float v0))
>      (unwind-protect 
>          (incf v0 1.0D0)
>        (setf (aref v 0) v0))))
>  (values))

I agree, that does not look right. Have a look at the macroexpand of the unwind protect form specifically:

(UNWIND-PROTECT
    (SETQ V0 (+ V0 1.0D0)) ; I removed the incf as it was littering the macroexpand
  (LET* ((#:FORM3987 V) (#:|Store-Var-3986| V0))
    (SETF::\"COMMON-LISP\"\ \"AREF\" #:|Store-Var-3986| #:FORM3987 0)))

Both #:FORM3987 and #:|Store-Var-3986| should have the types propagated by the compiler from the V and V0 vars respectively — but they evidently do not (or at least one of them doesn’t). It does not appear like it is a SETF problem as in the other case there is no boxing message, while the macroexpand is (give or take) the same:

(PROGN
  (SETQ V0 (+ V0 1.0D0))
  (LET* ((#:FORM3998 V) (#:|Store-Var-3997| V0))
    (SETF::\"COMMON-LISP\"\ \"AREF\" #:|Store-Var-3997| #:FORM3998 0)))

I wonder if it is false alarm, however? The value in the array upon return appears to be packed. Could be an iffy check in the source code of unwind-protect, or something.