Declarations as Assertions - SBCL 1.0.31 User Manual
Description: SBCL 1.0.31 User Manual

Next: Precise Type Checking, Up: Handling of Types

#### 4.2.1 Declarations as Assertions

The SBCL compiler treats type declarations differently from most other Lisp compilers. Under default compilation policy the compiler doesn't blindly believe type declarations, but considers them assertions about the program that should be checked: all type declarations that have not been proven to always hold are asserted at runtime.

> Remaining bugs in the compiler's handling of types unfortunately provide some exceptions to this rule, see Implementation Limitations.

CLOS slot types form a notable exception. Types declared using the `:type` slot option in `defclass` are asserted if and only if the class was defined in safe code and the slot access location is in safe code as well. This laxness does not pose any internal consistency issues, as the CLOS slot types are not available for the type inferencer, nor do CLOS slot types provide any efficiency benefits.

There are three type checking policies available in SBCL, selectable via `optimize` declarations.

Full Type Checks
  All declarations are considered assertions to be checked at runtime, and all type checks are precise. The default compilation policy provides full type checks.

  Used when `(or (>= safety 2) (>= safety speed 1))`.

Weak Type Checks
  Declared types may be simplified into faster to check supertypes: for example, `(or (integer -17 -7) (integer 7 17))` is simplified into `(integer -17 17)`.

  Note: it is relatively easy to corrupt the heap when weak type checks are used if the program contains type-errors.

  Used when `(and (< safety 2) (< safety speed))`

No Type Checks
  All declarations are believed without assertions. Also disables argument count and array bounds checking.

  Note: any type errors in code where type checks are not performed are liable to corrupt the heap.

  Used when `(= safety 0)`.