I haven't started a big flamewar and made fresh new enemies in what has
to be at least three weeks.  So.  Here goes.

I think we should change all the core string-manipulation functions to deal
gracefully with nil arguments.  Specifically, I want to change the smallest
set of functions that may originate the infamous "wrong-type-argument
(stringp, nil)" error, making them instead treat nil as if it were the
empty string.

By way of justification:

  * it's Lispy.  Yes, most Lisp dialects got strings wrong, but that
shouldn't
    stop us.  Strings are just character sequences, and whether you like it
or
    not, the nil/empty-list equivalence is part of Emacs's soul.  Throwing
an
    error on a nil string is a radical departure from the core philosophy.

  * wrong-type-argument (stringp, nil) is, anecdotally speaking, both the
most
    common error encountered by casual users and the most feared, because
    it's incredibly difficult to debug.  What's so hard about debugging it?
    It prevents Emacs from starting up!  So your debugger, evaluator, etc.
are
    all useless, and you're back to binary-partitioning of your .emacs file
until you
    find the offending code.  Setting debug-on-error works for more
experienced
    users, *when* it works (which, combined with --debug-init is not very
often).
    But even then, emacs stack traces are a poor-man's debugging tool at
best.

  * changing the behavior is unlikely to break much code.  Emacs libraries
should
    already do nil-checking on string arguments.  And nobody should be
relying
    on error conditions for normal control flow, so no code should be
depending
    on the string functions signaling this error.

The second argument is the real reason I've come to believe we're doing it
wrong.
Emacs has amazingly powerful runtime debugging facilities.  When Emacs is
running, it's *_*alive_, and you can help newbies debug problems by sending
them
snippets of code to evaluate on the fly.

If Emacs can't start up, or (worse) it gets into one of those horrid
scenarios where
some hook is throwing an error on almost every command and preventing the
user
from doing anything useful, then you're no longer in Emacs.  You're in
brokenville.
All the advantages and pleasure of Emacs as a dev environment have vanished.

In a way, I am arguing that Emacs is different from most other software, in
that
it is better for Emacs to fail silently and keep running than it is to fail
noisily and
prevent the user from doing any work.  This is not by any means an argument
you'd make about most software.  But over twenty-five years of daily Emacs
use,
I've decided that throwing errors on nil strings -- however good the
intentions may
have been -- is doing more harm than good.

Before you reject the idea out of hand, I'd like to ask that you consider
carefully
what behavior would be most consistent with the rest of Emacs, and would
make
best use of existing debugging and diagnostic facilities.

Compared to lexical scoping, this change is pretty minor. ;-)

-steve

p.s. (string= nil "") would still yield nil, of course.  I'm proposing
that we treat nil
as the empty string, not the other way around.