Mysteries of unwind-protect

Here'a a very minimal example of something which has been annoying me:

(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))

If you compile this in LW it will complain about boxing a float.  SBCL *also* complains about boxing a float.

This is because of the unwind-protect (the float it's boxing is the final setf).  If you replace this by

(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))
      (progn 
        (incf v0 1.0D0)
        (setf (aref v 0) v0))))
  (values))

It will not complain.

It looks to me like both implementations have lost track of the type of V somehow, and are worrying it may not be what it is.

Is there some reason I'm missing why it's not safe to assume the type of V here?  It seems odd that both LW and SBCL are saying the same thing otherwise.

It's not a big problem: this really only happens in a case of my bind-and-writeback macro that I probably never actually use, when you want the writebacks to happen even in the case of an error / non-local exit.

--tim

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html