Fix C warning if -DNDEBUG

[sbcl.git] / doc / manual / deprecation.texinfo

@node Deprecation
@comment  node-name,  next,  previous,  up
@chapter Deprecation

In order to support evolution of interfaces in SBCL as well as in user
code, SBCL allows declaring functions, variables and types as
deprecated. Users of deprecated things are notified by means of warnings
while the deprecated thing in question is still available.

This chapter documents the interfaces for being notified when using
deprecated thing and declaring things as deprecated, the deprecation
process used for SBCL interfaces, and lists legacy interfaces in various
stages of deprecation.

@dfn{Deprecation} in this context should not be confused with those
things the ANSI Common Lisp standard calls @dfn{deprecated}: the
entirety of ANSI CL is supported by SBCL, and none of those interfaces
are subject to censure.

@menu
* Why Deprecate?::
* The Deprecation Pipeline::
* Deprecation Conditions::
* Introspecting Deprecation Information::
* Deprecation Declaration::
* Deprecation Examples::
* Deprecated Interfaces in SBCL::
@end menu

@node Why Deprecate?
@comment  node-name,  next,  previous,  up
@section Why Deprecate?
@cindex Why Deprecate?

While generally speaking we try to keep SBCL changes as backwards
compatible as feasible, there are situations when existing interfaces
are deprecated:

@itemize

@item @strong{Broken Interfaces}

Sometimes it turns out that an interface is sufficiently misdesigned
that fixing it would be worse than deprecating it and replacing it
with another.

This is typically the case when fixing the interface would change its
semantics in ways that could break user code subtly: in such cases we
may end up considering the obvious breakage caused by deprecation to
be preferable.

Another example are functions or macros whose current signature makes
them hard or impossible to extend in the future: backwards compatible
extensions would either make the interface intolerably hairy, or are
sometimes outright impossible.

@item @strong{Internal Interfaces}

SBCL has several internal interfaces that were never meant to be used
in user code -- or at least never meant to be used in user code
unwilling to track changes to SBCL internals.

Ideally we'd like to be free to refactor our own internals as we
please, without even going through the hassle of deprecating things.
Sometimes, however, it turns out that our internal interfaces have
several external users who aren't using them advisedly, but due to
misunderstandings regarding their status or stability.

Consider a deprecated internal interface a reminder for SBCL
maintainers not to delete the thing just yet, even though it is seems
unused -- because it has external users.

When internal interfaces are deprecated we try our best to provide
supported alternatives.

@item @strong{Aesthetics & Ease of Maintenance}

Sometimes an interface isn't broken or internal, but just inconsistent
somehow.

This mostly happens only with historical interfaces inherited from
CMUCL which often haven't been officially supported in SBCL before, or
with new extensions to SBCL that haven't been around for very long in
the first place.

The alternative would be to keep the suboptimal version around
forever, possibly alongside an improved version. Sometimes we may do
just that, but because every line of code comes with a maintenance
cost, sometimes we opt to deprecate the suboptimal version instead:
SBCL doesn't have infinite developer resources.

We also believe that sometimes cleaning out legacy interfaces helps
keep the whole system more comprehensible to users, and makes
introspective tools such as
@findex @cl{apropos}
@code{apropos} more useful.

@end itemize

@node The Deprecation Pipeline
@comment  node-name,  next,  previous,  up
@section The Deprecation Pipeline
@cindex The Deprecation Pipeline

SBCL uses a @dfn{deprecation pipeline} with multiple stages: as time
goes by, deprecated things move from earlier stages of deprecation to
later stages before finally being removed. The intention is making users
aware of necessary changes early but allowing a migration to new
interfaces at a reasonable pace.

Deprecation proceeds in three stages, each lasting approximately a
year. In some cases it might move slower or faster, but one year per
stage is what we aim at in general. During each stage warnings (and
errors) of increasing severity are signaled, which note that the
interface is deprecated, and point users towards any replacements when
applicable.

@enumerate

@item @strong{Early Deprecation}

During early deprecation the interface is kept in working
condition. However, when a thing in this deprecation stage is used, an
@tindex @sbext{early-deprecation-warning}
@code{sb-ext:early-deprecation-warning}, which is a
@tindex @cl{style-warning}
@code{style-warning}, is signaled at
compile-time.

The internals may change at this stage: typically because the interface
is re-implemented on top of its successor. While we try to keep things
as backwards-compatible as feasible (taking maintenance costs into account),
sometimes semantics change slightly.

For example, when the spinlock API was deprecated, spinlock objects ceased
to exist, and the whole spinlock API became a synonym for the mutex
API -- so code using the spinlock API continued working, but silently
switched to mutexes instead. However, if someone relied on

   @code{(typep lock 'spinlock)}

returning @code{NIL} for a mutexes, trouble could ensue.

@item @strong{Late Deprecation}

During late deprecation the interface remains as it was during early
deprecation, but the compile-time warning is upgraded: when a thing in
this deprecation stage is used, a
@tindex @sbext{late-deprecation-warning}
@code{sb-ext:late-deprecation-warning},
which is a full
@tindex @cl{warning}
@code{warning}, is signaled at compile-time.

@item @strong{Final Deprecation}

During final deprecation the symbols still exist. However, when a thing
in this deprecation stage is used, a
@tindex @sbext{final-deprecation-warning}
@code{sb-ext:final-deprecation-warning},
which is a full
@tindex @cl{warning}
@code{warning}, is signaled at compile-time and an
@tindex @cl{error}
@code{error} is signaled at run-time.

@item @strong{After Final Deprecation}

The interface is deleted entirely.

@end enumerate

@node Deprecation Conditions
@comment  node-name,  next,  previous,  up
@section Deprecation Conditions
@cindex Deprecation Conditions

@tindex @sbext{deprecation-condition}
@code{sb-ext:deprecation-condition} is the superclass of all
deprecation-related warning and error conditions. All common slots and
readers are defined in this condition class.

@include condition-sb-ext-deprecation-condition.texinfo

@include condition-sb-ext-early-deprecation-warning.texinfo

@include condition-sb-ext-late-deprecation-warning.texinfo

@include condition-sb-ext-final-deprecation-warning.texinfo

@include condition-sb-ext-deprecation-error.texinfo

@node Introspecting Deprecation Information
@comment node-name,  next,  previous,  up
@section Introspecting Deprecation Information
@cindex Introspecting Deprecation Information
@comment TODO @findex @sbcltl{function-information}
@comment TODO @findex @sbcltl{variable-information}

The deprecation status of functions and variables can be inspected
using the @code{sb-cltl2:function-information} and
@code{sb-cltl2:variable-information} functions provided by the
@code{sb-cltl2} contributed module.

@node Deprecation Declaration
@comment  node-name,  next,  previous,  up
@section Deprecation Declaration
@cindex Deprecation Declaration
@findex @sbext{deprecated}

The @code{sb-ext:deprecated} declaration can be used to declare objects
in various namespaces@footnote{See ``namespace'' entry in the glossary
of the Common Lisp Hyperspec.} as deprecated.

@deffn {Declaration} @sbext{deprecated}

Syntax:
@example
@code{sb-ext:deprecated} stage since @{object-clause@}*

stage ::= @{:early | :late | :final@}

since ::= @{@var{version} | (@var{software} @var{version})@}

object-clause ::= (namespace @var{name} [:replacement @var{replacement}])

namespace ::= @{cl:variable | cl:function | cl:type@}
@end example

@noindent were @var{name} is the name of the deprecated thing,
@var{version} and @var{software} are strings describing the version in
which the thing has been deprecated and @var{replacement} is a name or a
list of names designating things that should be used instead of the
deprecated thing.

Currently the following namespaces are supported:

@table @code

@item cl:function
Declare functions, compiler-macros or macros as deprecated.

@quotation note
When declaring a function to be in @code{:final} deprecation, there
should be no actual definition of the function as the declaration emits
a stub function that signals a
@tindex @sbext{deprecation-error}
@code{sb-ext:deprecation-error} at run-time when called.
@end quotation

@item cl:variable
Declare special and global variables, constants and symbol-macros as
deprecated.

@quotation note
When declaring a variable to be in @code{:final} deprecation, there
should be no actual definition of the variable as the declaration emits
a symbol-macro that signals a
@tindex @sbext{deprecation-error}
@code{sb-ext:deprecation-error} at run-time when accessed.
@end quotation

@item cl:type
Declare named types (i.e. defined via @code{deftype}), standard classes,
structure classes and condition classes as deprecated.

@end table
@end deffn

@node Deprecation Examples
@comment  node-name,  next,  previous,  up
@section Deprecation Examples
@cindex Deprecation Examples

Marking functions as deprecated:
@lisp
(defun foo ())
(defun bar ())
(declaim (deprecated :early ("my-system" "1.2.3")
                     (function foo :replacement bar)))

;; Remember: do not define the actual function or variable in case of
;; :final deprecation:
(declaim (deprecated :final ("my-system" "1.2.3")
                     (function fez :replacement whoop)))
@end lisp

@noindent Attempting to use the deprecated functions:
@lisp
(defun baz ()
  (foo))
| STYLE-WARNING: The function CL-USER::FOO has been deprecated...
=> BAZ
(baz)
=> NIL ; no error

(defun danger ()
  (fez))
| WARNING: The function CL-USER::FEZ has been deprecated...
=> DANGER
(danger)
|- ERROR: The function CL-USER::FEZ has been deprecated...
@end lisp

@node Deprecated Interfaces in SBCL
@comment  node-name,  next,  previous,  up
@section Deprecated Interfaces in SBCL

This sections lists legacy interfaces in various stages of deprecation.

@subsection List of Deprecated Interfaces

@subsubsection Early Deprecation

@tindex @sbext{early-deprecation-warning}

@itemize

@item @strong{SOCKINT::WIN32-*}

Deprecated in favor of the corresponding prefix-less functions
(e.g. @code{sockint::bind} replaces @code{sockint::win32-bind}) as of
1.2.10 in March 2015. Expected to move into late deprecation in August
2015.

@sp 1
@item @strong{SB-UNIX:UNIX-EXIT}

Deprecated as of 1.0.56.55 in May 2012. Expected to move into late
deprecation in May 2013.

When the SBCL process termination was refactored as part of changes that
led to @code{sb-ext:quit} being deprecated, @code{sb-unix:unix-exit}
ceased to be used internally. Since @code{SB-UNIX} is an internal package
not intended for user code to use, and since we're slowly in the process
of refactoring things to be less Unix-oriented, @code{sb-unix:unix-exit}
was initially deleted as it was no longer used. Unfortunately it became
apparent that it was used by several external users, so it was re-instated
in deprecated form.

While the cost of keeping @code{sb-unix:unix-exit} indefinitely is
trivial, the ability to refactor our internals is important, so its
deprecation was taken as an opportunity to highlight that
@code{SB-UNIX} is an internal package and @code{SB-POSIX} should be
used by user-programs instead -- or alternatively calling the foreign
function directly if the desired interface doesn't for some reason
exist in @code{SB-POSIX}.

@strong{Remedy}

For code needing to work with legacy SBCLs, use e.g. @code{system-exit}
as show above in remedies for @code{sb-ext:quit}. In modern SBCLs
simply call either @code{sb-posix:exit} or @code{sb-ext:exit} with
appropriate arguments.

@sp 1
@item @strong{SB-C::MERGE-TAIL-CALLS Compiler Policy}

Deprecated as of 1.0.53.74 in November 2011. Expected to move into
late deprecation in November 2012.

This compiler policy was never functional: SBCL has always merged tail
calls when it could, regardless of this policy setting. (It was also
never officially supported, but several code-bases have historically
used it.)

@strong{Remedy}

Simply remove the policy declarations. They were never necessary: SBCL
always merged tail-calls when possible. To disable tail merging,
structure the code to avoid the tail position instead.

@sp 1
@item @strong{Spinlock API}

Deprecated as of 1.0.53.11 in August 2011. Expected to move into late
deprecation in August 2012.

Spinlocks were an internal interface, but had a number of external users
and were hence deprecated instead of being simply deleted.

Affected symbols: @code{sb-thread::spinlock},
@code{sb-thread::make-spinlock}, @code{sb-thread::with-spinlock},
@code{sb-thread::with-recursive-spinlock},
@code{sb-thread::get-spinlock}, @code{sb-thread::release-spinlock},
@code{sb-thread::spinlock-value}, and @code{sb-thread::spinlock-name}.

@strong{Remedy}

Use the mutex API instead, or implement spinlocks suiting your needs
on top of @code{sb-ext:compare-and-swap},
@code{sb-ext:spin-loop-hint}, etc.

@item @strong{SOCKINT::HANDLE->FD}, @strong{SOCKINT::FD->HANDLE}

Internally deprecated in 2012. Declared deprecated as of 1.2.10 in March
2015. Expected to move into final deprecation in August 2015.

@end itemize

@subsubsection Late Deprecation

@tindex @sbext{late-deprecation-warning}

@itemize

@item @strong{SB-THREAD:JOIN-THREAD-ERROR-THREAD and SB-THREAD:INTERRUPT-THREAD-ERROR-THREAD}

Deprecated in favor of @code{sb-thread:thread-error-thread} as of
1.0.29.17 in June 2009. Expected to move into final deprecation in
June 2012.

@strong{Remedy}

For code that needs to support legacy SBCLs, use e.g.:

@sp 1
@lisp
(defun get-thread-error-thread (condition)
  #+#.(cl:if (cl:find-symbol "THREAD-ERROR-THREAD" :sb-thread)
             '(and) '(or))
  (sb-thread:thread-error-thread condition)
  #-#.(cl:if (cl:find-symbol "THREAD-ERROR-THREAD" :sb-thread)
             '(and) '(or))
  (etypecase condition
   (sb-thread:join-thread-error
    (sb-thread:join-thread-error-thread condition))
   (sb-thread:interrupt-thread-error
    (sb-thread:interrupt-thread-error-thread condition))))
@end lisp
@sp 1

@sp 1
@item @strong{SB-INTROSPECT:FUNCTION-ARGLIST}

Deprecated in favor of @code{sb-introspect:function-lambda-list} as of
1.0.24.5 in January 2009. Expected to move into final deprecation in
January 2012.

Renamed for consistency and aesthetics. Functions have lambda-lists,
not arglists.

@strong{Remedy}

For code that needs to support legacy SBCLs, use e.g.:

@sp 1
@lisp
(defun get-function-lambda-list (function)
  #+#.(cl:if (cl:find-symbol "FUNCTION-LAMBDA-LIST" :sb-introspect)
             '(and) '(or))
  (sb-introspect:function-lambda-list function)
  #-#.(cl:if (cl:find-symbol "FUNCTION-LAMBDA-LIST" :sb-introspect)
             '(and) '(or))
  (sb-introspect:function-arglist function))
@end lisp
@sp 1

@sp 1
@item @strong{Stack Allocation Policies}

Deprecated in favor of @code{sb-ext:*stack-allocate-dynamic-extent*}
as of 1.0.19.7 in August 2008, and are expected to be removed in
August 2012.

Affected symbols: @code{sb-c::stack-allocate-dynamic-extent},
@code{sb-c::stack-allocate-vector}, and
@code{sb-c::stack-allocate-value-cells}.

These compiler policies were never officially supported, and turned
out the be a flawed design.

@strong{Remedy}

For code that needs stack-allocation in legacy SBCLs, conditionalize
using:

@sp 1
@lisp
#-#.(cl:if (cl:find-symbol "*STACK-ALLOCATE-DYNAMIC-EXTENT*" :sb-ext)
           '(and) '(or))
(declare (optimize sb-c::stack-allocate-dynamic-extent))
@end lisp
@sp 1

However, unless stack allocation is essential, we recommend simply
removing these declarations. Refer to documentation on
@code{sb-ext:*stack-allocate-dynamic*} for details on stack allocation
control in modern SBCLs.

@sp 1
@item @strong{SB-SYS:OUTPUT-RAW-BYTES}

Deprecated as of 1.0.8.16 in June 2007. Expected to move into final
deprecation in June 2012.

Internal interface with some external users. Never officially
supported, deemed unnecessary in presence of @code{write-sequence} and
bivalent streams.

@strong{Remedy}

Use streams with element-type @code{(unsigned-byte 8)}
or @code{:default} -- the latter allowing both binary and
character IO -- in conjunction with @code{write-sequence}.

@end itemize

@subsubsection Final Deprecation

@tindex @sbext{final-deprecation-warning}

No interfaces are currently in final deprecation.

@subsection Historical Interfaces

The following is a partial list of interfaces present in historical
versions of SBCL, which have since then been deleted.

@itemize

@item @strong{SB-KERNEL:INSTANCE-LAMBDA}

Historically needed for CLOS code. Deprecated as of 0.9.3.32 in August
2005. Deleted as of 1.0.47.8 in April 2011. Plain @code{lambda} can be
used where @code{sb-kernel:instance-lambda} used to be needed.

@sp 1
@item @strong{SB-ALIEN:DEF-ALIEN-ROUTINE, SB-ALIEN:DEF-ALIEN-VARIABLE, SB-ALIEN:DEF-ALIEN-TYPE}

Inherited from CMUCL, naming convention not consistent with preferred
SBCL style. Deprecated as of 0.pre7.90 in December 2001. Deleted as of
1.0.9.17 in September 2007. Replaced by
@code{sb-alien:define-alien-routine},
@code{sb-alien:define-alien-variable}, and
@code{sb-alien:define-alien-type}.

@end itemize