I opened an issue to discuss how to improve this: https://github.com/JuliaLang/julia/issues/7903
On Thu, Aug 7, 2014 at 7:33 PM, Stefan Karpinski <[email protected]> wrote: > 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 >>> >>> >
