bug#66890: 29.1; buffer-size should also accept the buffer's name as string argument

[Stefan Monnier]

Daniel wrote:
> My commentary in this particular case would be, that I dont see how now
> accepting strings in addition would shadow any future usage of that ( or
> other ) functions.

In most cases, the arg is meant to hold nothing but a buffer, and
allowing a string would probably not get in the way at all, indeed.

This said, there are functions out there that accept either buffers
or strings where the meaning of strings is not "buffer name" (e.g. where
a buffer is instead taken to mean "the `buffer-string` of that buffer"),
so we couldn't make it work "everywhere".

> Neither do I see how it would break function purity or
> side-effect-freeness, but that could just be my lack of imagination.

Agreed.  There is a slight cost to accepting strings, tho.
Not a very strong argument either, tho.

> As for the advantage my main argument would be convenience.  It does
> reduce user's elisp code

Does it?  Could you show some examples of the kind of reductions you're
thinking of?

> and and makes smaller evaluations in the minibuffer easier to type.

Indeed, it can be occasionally handy in `M-:`.

Eli wrote:
> I added Stefan Monnier to this discussion, in case he has an opinion
> on this issue, which seems now to be about a vast change in Emacs.

I do have an opinion on this: I wish I could go back in time and get rid
of this `buffer-or-string` business altogether.

The reason is that I've seen several ELisp packages which abused buffer
names as "handles" for buffers, leading to nasty bugs when those buffers
get renamed (e.g. by things like uniquify).

It's not important enough to motivate making backward
incompatible changes.

Maybe we should just "de-emphasize" the fact that those functions also
accept strings, and instead insist that you have to go through
`get-buffer` (or `get-buffer-create`).  If that sounds vague and you
don't know what that would mean concretely, well.. you're not alone :-)


        Stefan