Set[T].union methods and the like should accept Set[ST <: T]s as input.

[scabug]

Currently it's like

class Set[T]{
  def union(other:GenSet[T]):Set[T]
}

Which means that if B is a subclass of A,

val sa = Set(new A)
val sb = Set(new B)
val su:Set[A] = sa union sb

which is a simple request, results in a compile error. The Set[B] is invariant so it can't be taken as a Set[A] and union wont take Set[B]s for no reason I can imagine.
If, instead, the signature was

class Set[T]{
  def union[ST <: T](other:GenSet[ST]):Set[T]
}

everything would be golden.
The same criticism applies to the intersect method.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-9229?orig=1
Reporter: mako yass (makoConstruct)
Affected Versions: 2.11.4, 2.11.6

[scabug]

@Ichoran said:
This would break 2.11 and 2.12 source compatibility, which we're trying to maintain, but it looks like a great idea for 2.13.

[SethTisue]

@scala/collections did anything change here in 2.13? should the ticket remain open?

[som-snytt]

Looks like a missed opportunity?

union is concat but intersect as filter is less convenient.

Welcome to Scala 2.13.11 (OpenJDK 64-Bit Server VM, Java 20.0.1).
Type in expressions for evaluation. Or try :help.

scala> class A; class B extends A
class A
class B

scala> case class C(i: Int) extends A; case class D(i: Int) extends B
class C
class D

scala> val xs: Set[A] = Set(C(42), C(79), D(27))
val xs: Set[A] = Set(C(42), C(79), D(27))

scala> val ys: Set[B] = Set(D(27), D(28))
val ys: Set[B] = Set(D(27), D(28))

scala> xs union ys
                ^
       error: type mismatch;
        found   : Set[B] (in scala.collection.immutable)
        required: Set[A] (in scala.collection)

scala> xs concat ys
val res1: scala.collection.immutable.Set[A] = Set(C(42), C(79), D(27), D(28))

scala> xs & ys
            ^
       error: type mismatch;
        found   : Set[B] (in scala.collection.immutable)
        required: Set[A] (in scala.collection)

scala> xs filter ys
                 ^
       error: type mismatch;
        found   : Set[B]
        required: A => Boolean

scala> xs filter ys.contains
                    ^
       error: type mismatch;
        found   : B => Boolean
        required: A => Boolean

scala> import PartialFunction._
import PartialFunction._

scala> xs.filter(cond(_) { case b: B => ys(b) })
val res5: scala.collection.immutable.Set[A] = Set(D(27))

scala> ys filter xs
val res6: scala.collection.immutable.Set[B] = Set(D(27))

edit:

scala> xs.filter(ys exists _.==)
val res8: scala.collection.immutable.Set[A] = Set(D(27))

using the Starship Enterprise operator.

Also reminder that concat widens:

scala> xs.concat(Set("hello, world"))
val res9: scala.collection.immutable.Set[Object] = Set(C(42), C(79), D(27), hello, world)

scala> xs.filter(res9)
val res10: scala.collection.immutable.Set[A] = Set(C(42), C(79), D(27))

[SethTisue]

the increased flexibility would decrease type-safety, I suppose. (though there's also API consistency to consider, so it becomes a three-way balancing act...)

[Ichoran]

The current situation seems quite far from following the principle of least surprise in Scala 3.

union is identical conceptually to ++/concat and should have a compatible type signature, which in Scala 3 could be def union[B](sb: Set[B]): Set[A | B].

Intersection should really allow any type, but the signature would be def intersect[B](sb: Set[B]): Set[A & B]--after all, the extra elements that might be admitted in B but not A don't prevent the intersection from being computed, and you really should produce the empty set of Set[Nothing] or the equivalent by virtue of impossibility of being both types if the types don't intersect; that's a result, not necessarily an error.

Anything other than unifying set operations with Dotty's type calculus is probably not worth the effort. You have weird corner-cases regardless; may as well just learn the ones we've got and deal with them.

[som-snytt]

Someone was just asking in chat when does Scala 4 come out.