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, vav...@uwaterloo.ca
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
>
>
