So the trouble here is a) we don't have an abstract type for collections, and b) numbers and strings are both iterable. So all of these end up working, just not how you'd expect. If you iterate 19, it yields itself once, which is not equal to "abc". If you iterate "abc", you get 'a' then 'b' then 'c', none of which are equal to 19. Perhaps more disturbing is this:
julia> 97 in "abc" true Because 97 == 'a'. I really think we need to stop having characters be integers. On Thu, Aug 7, 2014 at 7:29 PM, <[email protected]> wrote: > Stefan, > > Here are some meaningless examples of in(.,.) that do not give an error > message: > > > julia> VERSION > v"0.3.0-rc2+12" > > julia> x = IntSet([3,5]) > IntSet([3, 5]) > > julia> in(3,x) > true > > julia> in(x,3) > false > > julia> in("abc",19) > false > > julia> in(19,"abc") > false > > -- Steve > > > > On Thursday, August 7, 2014 7:17:08 PM UTC-4, [email protected] wrote: >> >> I've noticed that the 'in' function appears to accept any pair of >> arguments; it returns 'false' in the case that the arguments make no sense. >> I suppose that some file has defined in(x::Any,y::Any) to be false. Why >> is this so? This definition appears to impede debugging because, for >> example, if a programmer accidentally reverses the two arguments to 'in()' >> or makes some less obvious blunder with types, no error message is issued. >> >> Thanks, >> Steve Vavasis >> >>
