+ It causes insertion of wrong type assertions into generated
+ code. E.g.
+
+ (defun foo (x s)
+ (let ((f (etypecase x
+ (character #'write-char)
+ (integer #'write-byte))))
+ (funcall f x s)
+ (etypecase x
+ (character (write-char x s))
+ (integer (write-byte x s)))))
+
+ Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
+
+ (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
+ produce invalid code, but type checking is not accurate. Similar
+ problems exist with VALUES-TYPE-INTERSECTION.)
+
+218: "VALUES type specifier semantics"
+ (THE (VALUES ...) ...) in safe code discards extra values.
+
+ (defun test (x y) (the (values integer) (truncate x y)))
+ (test 10 4) => 2
+
+220:
+ Sbcl 0.7.9 fails to compile
+
+ (multiple-value-call #'list
+ (the integer (helper))
+ nil)
+
+ Type check for INTEGER, the result of which serves as the first
+ argument of M-V-C, is inserted after evaluation of NIL. So arguments
+ of M-V-C are pushed in the wrong order. As a temporary workaround
+ type checking was disabled for M-V-Cs in 0.7.9.13. A better solution
+ would be to put the check between evaluation of arguments, but it
+ could be tricky to check result types of PROG1, IF etc.
+
+228: "function-lambda-expression problems"
+ in sbcl-0.7.9.6x, from the REPL:
+ * (progn (declaim (inline foo)) (defun foo (x) x))
+ FOO
+ * (function-lambda-expression #'foo)
+ (SB-C:LAMBDA-WITH-LEXENV NIL NIL NIL (X) (BLOCK FOO X)), NIL, FOO
+ but this first return value is not suitable for input to FUNCTION or
+ COMPILE, as required by ANSI.
+
+229:
+ (subtypep 'function '(function)) => nil, t.
+
+233:
+ Bug in constraint propagation:
+
+ (defun foo (x)
+ (declare (optimize (speed 2) (safety 3)))
+ (let ((y 0d0))
+ (values
+ (the double-float x)
+ (setq y (+ x 1d0))
+ (setq x 3d0)
+ (quux y (+ y 2d0) (* y 3d0)))))
+ (foo 4) => segmentation violation
+
+ (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS)