Re: Inconsistency in `string-to-number'

[Juanma Barranquero <lekktu@gmail.com>]

On Fri, Apr 24, 2009 at 16:06, Stefan Monnier<monnier@iro.umontreal.ca> wrote:

> Actually it could also break code (tho it seems unlikely).  I wouldn't
> mind postponing the fix to Emacs-23.2.  In the mean time, we need to
> improve the docstring.

The docstring was not improved, and we're now on the 23.2 track, so
time for a reprieve.

Reminder: The problem is the following inconsistency:

  (string-to-number "1:")  =>  1
  (string-to-number "1.2:")  =>  1
  (string-to-number "1.2") =>  1.2

Alas, the docstring talks about "leading spaces and tabs", but says
nothing about trailing chars.

Currently the behavior, depending of the first non-digit after the
number, is as follows:

 - \0, \s, \r, \n, \f and \t  => the number is read as a float (if
base == 10) or integer, as intended.
 - Any other char: the number is always interpreted as an integer.

Possibilities:

 0) Do nothing except clarifying the docs.
     Pro: easier of all fixes.
     Cons: inconsistency.

 1) Disallow any trailing char.
     Pro: follows the doc (sort of).
     Cons: incompatibility with current uses of undocumented "1:", etc.

 2) Allow only whitespace: the same chars that the float case admits right now.
     Pro: quite intuitive (IMO), easy to implement.
     Cons: Same as 1)

 3) Allow any trailing char.
     Pro: forgiving.
     Cons: (unlikely) incompatibility with uses of undocumented "1.2:" => 1

I like 2), because it seems cleaner to just allow whitespace all
around the number; it has a certain risk of incompatibility, though.
1) and 3) would require adding a new parameter to
lread.c:isfloat_string() or somesuch; not hard, but not very clean.

Thoughts?

    Juanma