Add infix `in` method (`element in collection`)

[GLI-RK0]

Proposal

Define a globally available infix method in(collection) for all types, enabling the following:

5 in Seq(1,5,3) // true
"cba" in "abc".permutations // true
'e' in "hello" // true
3 in (1 to 10) // true

1) Intuitive phrasing

There are many scenarios where asking whether an element is in a collection reads more intuitively than asking if a collection .contains an element.

if thing in Seq(............) then

vs

if Seq(............).contains(thing)

2) Generalizing membership checking, performantly.

Some collections kinds don't have a .contains method, like Iterator, where you would instead need to do .exists(_ == thing) to achieve the same meaning.
So, in could serve to generalize this operation -- sometimes working as an alias to .contains, and other times as an alias to .exists, while the high-level meaning is the same regardless so programmers don't need to think about this implementation detail. If you later change the underlying collection type, these callsites won't be impacted.

Implementation

It's possible to implement this for all collections performantly, through typeclasses. A few people on the discord gave a workable implementation here.

trait Membership[Item, Coll]:
  infix def in(col: Coll, item: Item): Boolean

object Membership:
  given seq: [A, S[x] <: Seq[x]] => Membership[A, S[A]]:
    override infix def in(seq: S[A], item: A): Boolean =
      seq.contains(item)
  given set: [A, S[x] <: Set[x]] => Membership[A, S[A]]:
    override infix def in(set: S[A], item: A): Boolean =
      set.contains(item)
  given iterable: [A] => Membership[A, Iterable[A]]:
    override def in(iter: Iterable[A], item: A): Boolean =
      iter.exists(_ == item)
// ...

Another example of an implementation

extension [A](a: A)
  def in[B >: A](col: Iterable[B]): Boolean =
    col match
      case seq: Seq[_] => seq.contains(a)
      case set: Set[_] => set.contains(a)
      case map: Map[_, _] => map.contains(a)
      case iter => iter.exists(_ == a)
// ...

It would be great to see this as a builtin method in the stdlib, free of any manual import requirements.

Thanks.

[SethTisue]

On part 1 (the infix question), I really doubt you'll get anywhere trying to get that added. It would be another way to say the same thing without a major benefit. As a rule, the collections API consistently doesn't offer minor syntactic variations like this. We've already picked method names and orders of arguments and we see more benefit in keeping those decisions consistent and the available methods not overlapping in functionality if possible, than in also offering variations to those who wish a different decision had been taken.

On part 2, could contains could be made available on more types? I see a roadblock to adding contains to Iterable: that Map[A, B] already offers a contains but it takes an A, not an (A, B). But Map[A, B] is a subtype of Iterable[(A, B)], so the signatures are incompatible.

A second issue to consider is variance. I haven't thought this through, but see past discussion at https://stackoverflow.com/questions/2925765/why-does-iterator-have-a-contains-method-but-iterable-does-not-in-scala-2-8 — any workable proposal to change contains needs to include evidence that you've considered the variance question. On the invariance of Set, see also https://stackoverflow.com/questions/676615/why-is-scalas-immutable-set-not-covariant-in-its-type ; contains comes up multiple times in the discussion in comments.

Iterable aside, that leaves open the possibility of adding contains to Iterator perhaps. It isn't obvious to me whether there's anything blocking that.

[GLI-RK0]

On part 1 (the infix question), I really doubt you'll get anywhere trying to get that added. It would be another way to say the same thing without a major benefit.

To clarify, the major benefit isn't the dotless infix form, but the flipped ordering of subject/object. thing.in(collection) would still read better in many scenarios than collection.contains(thing).

than in also offering variations to those who wish a different decision had been taken.

I'm not suggesting that collection.contains(thing) was a poor decision, there are scenarios when this ordering reads more intuitively also. I think offering both is a good idea.

x ∈ set is another way of saying set ∋ x, and it is still useful to have those both as standard notations. Having both to and until for ranges is similar, I could always express 1 <= x <= 10 through 1 until 11, but having a separate 1 to 10 improves comprehension.

[BalmungSan]

On part 1 (the infix question), I really doubt you'll get anywhere trying to get that added. It would be another way to say the same thing without a major benefit. As a rule, the collections API consistently doesn't offer minor syntactic variations like this.

While I understand this policy, and those who know me know that I am usually against excessive sugar.
IMHO, this in extension would really help with readability and help with the overall vibe Scala 3 has, syntax-wise; e.g., the whitespace version for if then else.
This, and a not extension, are the only two syntactic additions that I personally have always wanted to see.

Additionally, I believe that the typeclass solution proposed in this Scastie (disclaimer, I am the author): https://scastie.scala-lang.org/BalmungSan/qKAA8jyGTjuqnZQ59dPFLw/18 shows that this addition can be very flexible and powerful. Supporting multiple collection-like types, like Range or String. Allowing for multiple cases like key in map and (key -> value) in map, or char in str and substr in str. Plus, since it is a typeclass, downstream users could extend it to add support to custom types; e.g., cats-collections, fs2 Chunk, etc.
This solution also avoids all the subtype-related and variance-related problems Seth mentioned. Plus, I believe we could add some inlines here and there to make the syntax have zero cost and always translate to something like collection.contains(item).