I have two remarks:

1. It may be reasonable to add the stage 0: the announcement of the future deprecation on sbcl-devel, just to hear the early complains (if any).
2. In general, undefined behaviors are not so good idea. Whenever possible, it is better to stop on stage 3. The exception should be made only in case of noticeable performance benefits which are the result of 3->4 transition (if any).

Also, it is possible to use #+-obsolete or something like this in the sources, and build two SBCL versions: with the deprecated stuff errors included for testing purposes, and without them.

Obviously, all the above is just my IMHO. Finally, I support the idea to add the deprecation rules and to obey them.


2010/11/16 Nikodemus Siivola <nikodemus@random-state.net>
I would like to be a bit more orderly about deprecating stuff in SBCL.

What I have in mind is a three/four-stage process:

1. Early deprecation. Signal a compile-time style-warning.

2. Late deprecation. Signal a compile-time full warning.

3. Final deprecation. Signal a compile-time full warning and a run-time error.

4. Really gone. Remove even the deprecation error -- just let the
undefined-whatever, etc happen.

I think 1->2 transition should take about 6 months, and 2->3 a year,
with 4 following a year after that. (I'm really thinking
month=point-release and year=full-release.) These frequencies are
based on the reported update frequencies here:


I would make all deprecation warnings subclasses of
SB-EXT:DEPRECATION-WARNING, so that even stage 1 is easy to detect.

Any thoughts?

I don't personally mind carrying traces of old things for a fair
while, but if the consensus favors a faster or slower pace I'm OK with
that. The most important transition IMO is 1->2: stage 1 should give
people sufficient time to fix their stuff before it actually breaks.
The second most important transition is IMO 3->4: at point 4 the error
becomes impenetrable to the casual user.

This isn't just blue-sky: while working on prettier backtraces I
concluded that the &OPTIONAL interface used by BACKTRACE is better
replaced with another, and plan to deprecate it in favor of
PRINT-BACKTRACE using &KEY arguments.


 -- Nikodemus

Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
Sbcl-devel mailing list