From 6dd0b1517933b7efbc77fd7f16a2b6f6da477347 Mon Sep 17 00:00:00 2001 From: Nikodemus Siivola Date: Thu, 7 May 2009 16:48:04 +0000 Subject: [PATCH] 1.0.28.25: document CLOS slot type checking policy ...especially since given our normal declarations-are-assertions policy it is somewhat surprising. --- NEWS | 1 + doc/manual/compiler.texinfo | 34 ++++++++++++++++++++-------------- version.lisp-expr | 2 +- 3 files changed, 22 insertions(+), 15 deletions(-) diff --git a/NEWS b/NEWS index 79cdb7a..31d6f03 100644 --- 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 --- 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 --- 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" -- 1.7.10.4