define generic in in terms of any

[matthias314]

I think that the current implementation of x in itr is identical to any(==(x), itr), see below. An added bonus of calling any is that a more efficient implementation of any for a custom type will most likely give an efficient implementation of in for that type at the same time.

julia/base/reduce.jl

Lines 1220 to 1238 in 3a2a4d8

	any(f, itr) = _any(f, itr, :)
	for ItrT = (Tuple,Any)
	# define a generic method and a specialized version for `Tuple`,
	# whose method bodies are identical, while giving better effects to the later
	@eval function _any(f, itr::$ItrT, ::Colon)
	$(ItrT === Tuple ? :(@_terminates_locally_meta) : :nothing)
	anymissing = false
	for x in itr
	v = f(x)
	if ismissing(v)
	anymissing = true
	else
	v && return true
	end
	end
	return anymissing ? missing : false
	end
	end

[adienes]

big thumbs up to remove special-cased missing logic !

[aviatesk]

LGTM.

[mikmoore]

This doesn't pertain to the current PR, which merely matches the existing behavior of using ==.

But I will gripe that in's ambiguity on the subject of == vs isequal is awful:

  in(item, collection) -> Bool
  ∈(item, collection) -> Bool

  Determine whether an item is in the given collection, in the sense that it is == to one of the values generated by
  iterating over the collection. Return a Bool value, except if item is missing or collection contains missing but not
  item, in which case missing is returned (three-valued logic (https://en.wikipedia.org/wiki/Three-valued_logic),
  matching the behavior of any and ==).

  Some collections follow a slightly different definition. For example, Sets check whether the item isequal to one of
  the elements; Dicts look for key=>value pairs, and the key is compared using isequal.

I find the choice of == to be questionable with regard to AbstractFloat behavior

julia> -0.0 in [+0.0] # debatable, but if I wanted `==` or `a <= b <= c` I probably should have written that
true

julia> NaN in [NaN] # these are `===`
false

and think the fact that Set (and others?) has different behavior is abhorrent

julia> -0.0 in Set([+0.0])
false

julia> NaN in Set([NaN])
true

[aviatesk]

Since that behavior is clearly stated in the docstring, I assume it's the result of a lengthy discussion. Rather than debating it in this PR, it seems more appropriate to discuss it in a separate issue.

[aviatesk]

@nanosoldier runbenchmarks(!"scalar", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[matthias314]

It's hard for me to interpret the benchmark results. Do they show any problem?