If anybody is interested and missed it the first time around, there is some good discussion of this in https://github.com/JuliaLang/julia/issues/7903.
On Thu, Sep 10, 2015 at 2:01 PM, Randy Zwitch <[email protected]> wrote: > How do you enumerate all of the cases that are "oddball"? > > julia> [1,2,3] in Any[[1],[2],[3],[1,2,3]] > > true > > > julia> [1,2,3] in [[1],[2],[3],[1,2,3]] > > false > > > In the first case, because I declare the array of type "Any", I have an > Array of Arrays (Array{Any, 1}). In that case, the "in" statement is > perfectly valid to test for and is true. > > > In the second case, you get false. What's difficult here is that I think the > compiler is confused due to the change in concentation syntax: > > > julia> typeof([[1],[2],[3],[1,2,3]]) > > WARNING: [a,b,...] concatenation is deprecated; use [a;b;...] instead > > in depwarn at ./deprecated.jl:73 > > in oldstyle_vcat_warning at ./abstractarray.jl:29 > > in vect at abstractarray.jl:32 > > while loading no file, in expression starting on line 0 > > Array{Int64,1} > > > > I'm not proposing a solution, just highlighting that it would be pretty > difficult to protect everyone from themselves. At some point, people need to > be precise about what they mean. > > > > > On Thursday, September 10, 2015 at 12:59:59 PM UTC-4, [email protected] > wrote: >> >> 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 >> >
