Subject: bug#76055: 29.4; Doc of string-empty-p

From: Drew Adams <[email-masked]>
Date: Wed, 5 Feb 2025 23:30:38 +0000

> > The doc string should tell you that it treats a symbol for arg STRING,
> > instead of a string, by checking its `symbol-name'.  E.g., like what is
> > done for `string=':
> >
> >  Symbols are also allowed; their print names are used instead.
> 
> FWIW, I'm not suggesting any changes, but I admit that I never really
> understood this design decision.
> 
> This is what I get in Guile:
> 
>     scheme@(guile-user)> (string=? "foo" 'foo)
>     ice-9/boot-9.scm:1676:22: In procedure raise-exception:
>     In procedure string=: Wrong type argument in position 2 (expecting
> string): foo
> 
> And in SBCL:
> 
>     * (string= "foo" 'foo)
>     NIL
> 
>     * (string= "foo" 123)
> 
>     debugger invoked on a SIMPLE-TYPE-ERROR in thread
>     #<THREAD tid=259 "main thread" RUNNING {7004FF0003}>:
>       123 is not a string designator.

I'm not at all raising the question of it raising or
not raising an error if the arg isn't a string (i.e.,
"rejecting" the arg, as Alfred put it).

Elisp does the same as Scheme and SBCL for a non-symbol
non-string.  (But note SBCL's handling of a symbol, BTW.)

I _like_ Elisp's `string=' behavior and doc.  It says:
I'm a function that checks whether two strings are equal.
The args must be strings or I'll raise an error.
Oh wait, I do also accept symbols, and for them I use
their `symbol-name's, but that's the only non-string
exception.

[ I could also like a behavior that raised an error for
all non-string args, i.e., including symbols.  I could
also like a behavior that returned nil for a non-string
arg (any non-string arg).  That latter behavior would
just be a test whether the args are strings AND if so,
are equal. ]

`string-empty-p' should be just as polite and user
friendly as `string='.