1.0.28.25: document CLOS slot type checking policy

  ...especially since given our normal declarations-are-assertions
  policy it is somewhat surprising.

diff --git a/NEWS b/NEWS
index 79cdb7a..31d6f03 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -5,6 +5,7 @@
   * optimization: multidimensional array accesses in the absence of type
     information regarding array rank are approximately 10% faster due to
     open coding of ARRAY-RANK.
+  * documentation: CLOS slot typechecing policy has been documented.
   * bug fix: potential miscompilation of array stack allocation on x86 and
     x86-64. (reported by Time Tossavainen)
   * bug fix: some forms of AND, OR, and COND resulted in expansions that could

diff --git a/doc/manual/compiler.texinfo b/doc/manual/compiler.texinfo
index 9a3533d..2e0be37 100644 (file)
--- a/doc/manual/compiler.texinfo
+++ b/doc/manual/compiler.texinfo
@@ -456,11 +456,10 @@ one level.
 @comment  node-name,  next,  previous,  up
 @section Handling of Types
 
-The most unusual features of the SBCL compiler (which is very
-similar to the original CMUCL compiler, also known as @dfn{Python})
-is its unusually sophisticated understanding of the Common Lisp type
-system and its unusually conservative approach to the implementation
-of type declarations.
+One of the most important features of the SBCL compiler (similar to
+the original CMUCL compiler, also known as @dfn{Python}) is its fairly
+sophisticated understanding of the Common Lisp type system and its
+conservative approach to the implementation of type declarations.
 
 These two features reward the use of type declarations throughout
 development, even when high performance is not a concern. Also, as
@@ -493,21 +492,28 @@ involving the @code{satisfies} type specifier.
 @subsection Declarations as Assertions
 @findex safety
 
-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.
+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.
 
 @quotation
 @emph{Remaining bugs in the compiler's handling of types unfortunately
 provide some exceptions to this rule, see @ref{Implementation
-Limitations}).}
+Limitations}.}
 @end quotation
 
-There are three type checking policies available in SBCL,
-selectable via @code{optimize} declarations.
+CLOS slot types form a notable exception. Types declared using the
+@code{:type} slot option in @code{defclass} are asserted if and only
+if the class was defined in @emph{safe code} and the slot access
+location is in @emph{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 @code{optimize} declarations.
 
 @table @strong
 

diff --git a/version.lisp-expr b/version.lisp-expr
index e86b8dc..19d086a 100644 (file)
--- a/version.lisp-expr
+++ b/version.lisp-expr
@@ -17,4 +17,4 @@
 ;;; checkins which aren't released. (And occasionally for internal
 ;;; versions, especially for internal versions off the main CVS
 ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"1.0.28.24"
+"1.0.28.25"