bug#21391: 24.5; `thing-at-point' should return a string

[Eli Zaretskii <eliz@gnu.org>]

> Cc: tino.calancha@gmail.com, 21391@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 7 Nov 2016 22:03:58 +0200
> 
>     Didn't the function behave that way for quite some time?  If so, how
>     come it's suddenly a problem?
> 
> Someone tried to use it for the first time?

I'm not sure what issue we are discussing and what problem we are
trying to solve.  Let me take a step back and describe the situation
as I see it.

This bug report started because thing-at-point would signal an error
for some of its calls.  That bug is already fixed.  Tino was unhappy
with using sequencep and wanted to replace that with stringp -- fine
with me, I don't object to such a change.

From my POV the issue should be closed once we agree on the predicate
to use when deciding whether or not stripping the text properties is
appropriate.

But then somehow the discussion shifted to be about whether to _force_
thing-at-point value to be a string, even if it isn't for some reason.
I don't understand the rationale for such a change.  Yes,
thing-at-point was most probably always meant to return a string.
Yes, Lisp code that causes it to return some other object is probably
wrong.  However, the change that allowed this was introduced 19 years
ago; who knows what code out there actually uses this loophole?  If
there is such code, why would we want to break it?  To what end?  And
if no code uses this loophole, why do we care that it exists?

IOW, thing-at-point no longer has any known bugs, and we are talking
about forcibly breaking a use case that does no harm to us, and can
only happen if someone abuses the 'thing-at-point' property, which
would make it that someone's bug/misfeature, for them to fix.

So why would we want to make such a change?  What am I missing?