FIND-RESTART, when given a RESTART, omits to check if the restart is still active according to its test-function and condition-restarts associations
What I do:
(let ((activep t))
;; Inactive because of condition-restarts associations.
;; Inactive because of test-function.
(setf activep nil)
What I expected to happen:
From CLHS FIND-RESTART:
"If identifier is a currently active restart, then it is returned. Otherwise, nil is returned."
I'm pretty sure a restart is not considered "active" if its test-function returns false.
I'm less sure about condition-restarts associations, but I think the same behavior (returning NIL) should apply.
The only way to test if a RESTART that you have in your hands is still valid is to call FIND-RESTART on it, since there's no portable way to query condition-restarts associations or call a RESTART's test-function directly. It might be possible to test the restart for validity by trying to FIND-RESTART its RESTART-NAME, but this is inefficient, unidiomatic, error-prone (this restart might have been shadowed by another restart of the same name since FIND-RESTART was called the first time), and convoluted compared to just using the restart itself.
Note that INVOKE-RESTART has the same type of problem (calling the restart-function when given an actual restart as argument while still in its dynamic extent yet being inactive because of condition-restarts associations or test-function returning false), but in SBCL INVOKE-RESTART indirectly invokes FIND-RESTART so this is really the same problem...
From CLHS INVOKE-RESTART:
"If restart is not valid, an error of type control-error is signaled."
SBCL version: 1.0.42
uname -a: Linux dynamorph 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux
(:SWANK :QUICKLISP :SB-BSD-
:SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL
:LARGEFILE :GENCGC :STACK-
:CYCLE-COUNTER :INLINE-CONSTANTS :MEMORY-