About a year ago I proposed on this forum that 'in' should do more
type-checking. For example, the expression
[1,2,3] in [1,2,3,4]
is almost certainly a programmer error. But Julia accepts it without
complaint and returns 'false'. I myself have had problems with the wrong
version of 'in' getting called and nonsensical results returned.
The argument raised against this proposal was the following. According to
Julia semantics, "a in b" is equivalent to
for x in b
if x==a
return true
end
end
return false
But in fact, as the Julia 0.4 recent masters show, there are at least two
cases in which 'in' does not follow these semantics and returns an error if
it thinks the programmer made a mistake. (See the trace below-- both are
cases where Julia 0.4 changed behavior from 0.3).
It is important for Julia to be vigilant about catching obvious programmer
errors. This will help improve its chances for use in introductory
programming courses at universities, among other reasons.
I propose the following: In Julia 0.5, Base should be broken up into Base
and ExpansiveBase. Functions like in(x::Any,itr::Any) from reduce.jl or
start(x::Number) from number.jl that allow oddball user code to be accepted
by the compiler would be put into ExpansiveBase. The semantics for
'in(a,b)' when only Base is loaded should be either typeof(a)==eltype(b) or
that there exists a method convert(eltype(b),a).
-- Steve Vavasis
julia> 0 in IntSet()
WARNING: stored zeros in IntSet is deprecated
in depwarn at deprecated.jl:63
in in at intset.jl:163
while loading no file, in expression starting on line 0
false
julia> (1,2) in Dict{Any,Any}()
ERROR: Associative collections only contain Pairs;
Either look for e.g. A=>B instead, or use the `keys` or `values`
function if you are looking for a key or value respectively.
in in at dict.jl:13
