isnumber("") return true

[songroom]

julia> isnumber("")
true

julia> versioninfo()
Julia Version 0.4.1
Commit cbe1bee* (2015-11-08 10:33 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

[yuyichao]

This seems to be consistent with the doc.

Tests whether a character is numeric, or whether this is true for all elements of a string.

An empty string trivially satisfies this.

[nalimilan]

One could equally well argue that false should be returned in that case. I'd rather raise an exception, especially given that "" is currently the only string for which isnumber is true which cannot be parsed as a (big) integer:

julia> parse(Int, "")
ERROR: ArgumentError: premature end of integer: ""

[yuyichao]

It's consistent with other similar functions and I don't think it's a good idea to make some of them special.

[yuyichao]

Also note that isnumber supports unicode Number category so "" is far from the only thing that can't be parsed as an integer.

julia> isnumber("¼")
true

julia> parse(Int, "¼")
ERROR: ArgumentError: invalid base 10 digit '¼' in "¼"
 [inlined code] from ./strings/io.jl:66
 in tryparse_internal at ./parse.jl:92
 in tryparse_internal at ./parse.jl:136
 in parse at ./parse.jl:146

[nalimilan]

I must admit it's also consistent with all:

julia> all(Bool[])
true

Looks like this is a well-established principle: https://en.wikipedia.org/wiki/Vacuous_truth

But this gives rise to funny results like isupper("") & islower("") == true.

[JeffBezanson]

I think it would be better not to implicitly lift these functions to strings, and write all(isnumber, str).

[yuyichao]

Let's do that when jb/functions is ready.

[kshyatt]

jb/functions was ready, wasn't it? Can we make this change now?

[tkelman]

yes though ideally it should be a deprecation so there's a limited window to get this into 0.6

[StefanKarpinski]

Let's go ahead and deprecate the auto-vectorised version here.

[StefanKarpinski]

I also think this is a pretty surprising function since I would expect it to have something to do with the Number type and it doesn't at all – instead it has to do with string parsing.

[JeffBezanson]

This also applies to all the other digit predicates, isprint, ispunct, islower, iscntrl, isalpha, etc. We can deprecate all of them, with the possible exception of isascii(string) which seems reasonable.

[nalimilan]

PR #14387 merged all these functions into a single charprop function, to which one would pass the requested property type. I still think it's a good idea and I could rebase the relevant part if you like.

[StefanKarpinski]

Yes please – let's go with that.

[JeffBezanson]

That PR was pretty controversial, and also orthogonal to whether character property testing is lifted to strings.

[nalimilan]

I don't think the contents of the PR were very controversial, except for the parts I debated in a long discussion with Scott (i.e. whether to use types or not). But you're right it's mostly orthogonal to this issue, I was just reacting to your statement "we can deprecate all of them".