Previous: Getting Existing Programs to Run, Up: Handling of Types

#### 4.2.4 Implementation Limitations

Ideally, the compiler would consider all type declarations to be assertions, so that adding type declarations to a program, no matter how incorrect they might be, would never cause undefined behavior. However, the compiler is known to fall short of this goal in two areas:

- Proclaimed constraints on argument and result types of a function are supposed to be checked by the function. If the function type is proclaimed before function definition, type checks are inserted by the compiler, but the standard allows the reversed order, in which case the compiler will trust the declaration.
- The compiler cannot check types of an unknown number of values; if the number of generated values is unknown, but the number of consumed is known, only consumed values are checked.

  For example,

                (defun foo (x)
                  (the integer (bar x)))

  causes the following compiler diagnostic to be emitted:

                ; note: type assertion too complex to check:
                ;  (VALUES INTEGER &REST T).

  A partial workaround is instead write:

                (defun foo (x)
                  (the (values integer &optional) (bar x)))

These are important issues, but are not necessarily easy to fix, so they may, alas, remain in the system for a while.