[Sbcl-devel] deprecating stuff

[Nikodemus S. <nik...@ra...>]

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:

  http://random-state.net/sbcl-survey-2010-results.html

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.

Cheers,

 -- Nikodemus