RE: Declaring cl.el obsolete

[Drew Adams <drew.adams@oracle.com>]

> > cl-lib was released 6 years ago...
> > everything it offers is provided by cl-lib or lexical-binding.

Maybe.  When those are available, which they're
not for some older releases.  And not everything:
aliases to names without `cl-' are missing.

> In the ensuing discussions, there have been the following objections:
> 1- Eli doesn't like using "obsolete" and would prefer "deprecated".
> 2- Lars pointed out that `cl` is still in fairly wide use outside of
> Emacs.
> 3- Ken explained that he prefers the non-prefixed names.
> 
> Regarding (3), I know several people feel that way, and that's a valid
> preference, but I see no reason why the `cl` package satisfying this
> preference needs to be distributed with Emacs.
> 
> Regarding (2), I pointed out that I don't foresee `cl` disappearing
> completely any time soon.  Instead, it will likely move to GNU ELPA
> when we finally remove it from Emacs.
> 
> As for (1), I used the word "deprecated".
> 
> So any remaining objection to the patch below?

I don't really want to get into this can of worms,
but I guess I should say what I think.

1. Some code will continue to use `cl.el', at least
   for compatibility with both older and newer Emacs
   versions.  Even for compilation-time use of macros.
   Some older Emacs versions don't have `cl-lib.el'
   (or `cl-macs.el').  Even `lexical-let' and `flet',
   however imperfect, are important for older versions.

2. What's the reason why names with no prefix, that
   do not conflict with any Emacs names, can't be
   included in `cl-lib.el' as aliases?  I'm thinking
   of names like `case', `incf', `multiple-value-bind',
   `typecase', `gentemp', `pushnew', `delete-if',
   `loop', `decf', and `(delete|remove)-duplicates'.
   (In my code, `case' is the most commonly used.)

   They are aliased in `cl.el' (see #1).  Without
   supporting the aliases, code that's compatible
   with older releases can't use the aliases, and it
   also can't use the `cl-' versions, which don't
   exist.

3. Moving `cl.el' to GNU ELPA doesn't help its use
   by older Emacs versions that don't support
   package.el.

I see only bother for users in the proposal.  I'm
sure it would reduce some maintenance for Emacs
dev, but how much?  And is that worth the bother
for users and (at least some) 3rd-party libraries?

My vote: -1.