These are the methods of in:
julia> methods(in)
# 14 methods for generic function "in":
in{T<:Integer}(x,r::Range{T<:Integer}) at range.jl:566
in(x,r::Range{T}) at range.jl:562
in(x::Number,y::Number) at number.jl:40
in(n::Integer,s::IntSet) at intset.jl:125
in(p::(Any,Any),a::Associative{K,V}) at dict.jl:10
in{T<:Dict{K,V}}(key,v::KeyIterator{T<:Dict{K,V}}) at dict.jl:629
in(k::String,::KeyIterator{EnvHash}) at env.jl:101
in(k,v::KeyIterator{T<:Associative{K,V}}) at dict.jl:162
in(x,s::Set{T}) at set.jl:16
in(c::Char,s::String) at string.jl:201
in(::String,::String) at string.jl:471
in(v::VersionNumber,i::VersionInterval) at pkg/types.jl:15
in(v::VersionNumber,s::VersionSet) at pkg/types.jl:38
in(x,itr) at reduce.jl:400
Were you by chance doing something like 1 in 2?
On Thu, Aug 7, 2014 at 7:17 PM, <[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
>
>
