Possible issues found adding coverage tests

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible issues found adding coverage tests

Scott Jones
I noticed something rather strange with eltype, but not sure exactly how this might cause bugs.

julia> x = eachindex("foobar")

Base.EachStringIndex{ASCIIString}("foobar")


julia> typeof(x)

Base.EachStringIndex{ASCIIString}


julia> eltype(Base.EachStringIndex{ASCIIString})

Any


julia> eltype(Base.EachStringIndex)

Int64


Is it expected that eltype of the parameterized type returns Any, even though there is a specific method so that EachStringIndex returns Int?


I also noticed that the methods lcfirst and ucfirst (which only ucfirst is used anywhere, and only in a couple of packages), are not really stable as to their results.

If the input is not changed, the type is the same as the input, but if it does change the first character, then the result will always be either ASCIIString or UTF8String (map had the same problem of type stability, which I'd fixed a while ago)

Should I fix this as well at some point?

Also, it seems like lcfirst and ucfirst might be better in a string utility package (along with a host of other string things that aren't frequently used).  Would people object to that at some point in the future?


Another thing that is confusing is the use of integers that are stored in Floats as indexes:

julia> getindex('a',1,1)

'a'


julia> getindex('a',1,1.0)

WARNING: indexing with non Integer Reals is deprecated

 in depwarn at ./deprecated.jl:73

 in to_index at deprecated.jl:427

 in getindex at char.jl:22

while loading no file, in expression starting on line 0

'a'



Does that mean that indexing with anything whose *type* is not "Integer" (or a subtype) is deprecated?

1.0 *is* an integer, so the warning seems a bit confusing, and I'd thought I'd seen a PR that allowed those again.


Another thing I came across was that there is a lot of inconsistency in handling Char[], SubString("",1,1), "", utf8(""),

utf16(""), and utf32("") with search, rsearch, searchindex, rsearchindex.

I would think all of them should act exactly the same, but some give errors, some give different results with the same start position.

Shouldn't search("foo","o",4) throw a BoundsError, since the start is after the end of the string?


Thanks,

Scott



Reply | Threaded
Open this post in threaded view
|

Re: Possible issues found adding coverage tests

Mauro

On Tue, 2015-09-01 at 00:55, Scott Jones <[hidden email]> wrote:

> I noticed something rather strange with eltype, but not sure exactly how
> this might cause bugs.
>
> *julia> **x = eachindex("foobar")*
>
> *Base.EachStringIndex{ASCIIString}("foobar")*
>
>
> *julia> **typeof(x)*
>
> *Base.EachStringIndex{ASCIIString}*
>
>
> *julia> **eltype(Base.EachStringIndex{ASCIIString})*
>
> *Any*
>
>
> *julia> **eltype(Base.EachStringIndex)*
>
> *Int64*
>
>
> Is it expected that eltype of the parameterized type returns Any, even
> though there is a specific method so that EachStringIndex returns Int?

The method definition in basic.jl reads:
  eltype(::Type{EachStringIndex}) = Int
but probably should read:
  eltype{T<:EachStringIndex}(::Type{T}) = Int