I was surprised to see this behavior
scala> Option(1) == Option(2)
1 |Option(1) == Option(2)
|^^^^^^^^^^^^^^^^^^^^^^
|Values of types Option[Int] and Option[Int] cannot be compared with == or !=
scala> Vector(1) == List(2)
val res3: Boolean = falseWhy is there a default value for collection.Seq[T] but not Option[T]?
@sjrd I have a question about the execution of the workflow file
ci.yaml on the Windows runner : does it matter if I split the runner command sbt ";sjsJUnitTests/test ;sjsCompilerTests/test" in two steps, i.e. sbt ";sjsJUnitTests/test"and then "sbt ;sjsCompilerTests/test" ? PS: I have memory issues when running my Actions on my GitHub-hosted Windows runner (2 cpus + 8 GB versus 4 cpus + 24 GB at EPFL)
@olafurpg like all language flags, strictEquality is barely tested and probably not really usable, I wouldn't recommend using it.
@smarter fair enough. I was trying it out following your suggestion in https://github.com/scalameta/munit/issues/189#issuecomment-702292672 :p
Do you think it's worth opening a "bug report" with the example above?
I'm planning to use
Eql in MUnit scalameta/munit#225 I think it would be really nice to be able to use multiversal equality for cases like this
it sounds like you disagree on what should and should not be equal (Int and Char, ...), so https://contributors.scala-lang.org/ would be more appropriate for open-ended discussions
we could add Option to the instances in https://github.com/lampepfl/dotty/blob/master/library/src/scala/Eql.scala, but that doesn't really scale, so I assume you'd want different rules to handle this, so you'd need to come up with rules and propose them
@smarter Fair enough, I opened https://contributors.scala-lang.org/t/should-multiversal-equality-provide-default-eql-instances/4574
I agree it would not scale to add Option[T] instances to theEql object, a better approach would be to remove all of the default instances to give users 100% control over what types are safe to compare with each other. I am concerned this new language feature won't gain widespread adoption in its current form.
final case class Universe() {
case class Needle()
def findNeedle(n: Needle) = n
}
// Doesn't compile
def find1[U <: Universe with Singleton](u: U, n: U#Needle) = { u.findNeedle(n) }
// Compiles
def find2[U <: Universe with Singleton](u: U)(n: u.Needle) = { u.findNeedle(n) }
Why does
find1 not compile?
also you don't need two parameter lists for dependent params in dotty
(also type projections on abstract types are unsound in general and should be avoided)
This compiles in Scala 2.13 but not in Dotty, how should I go about doing similar things?
final case class Universe() {
val needle = Needle()
case class Needle() {
def combine(other: Needle): Needle = ???
}
def findNeedle(n: Needle) = n
}
def combine[U <: Universe with Singleton](n1: U#Needle, n2: U#Needle) = { n1.combine(n2) }n1 doesn't have Needle since it is Needle
def combine[U <: Universe, N <: U#Needle](n1: N, n2: N) maybe
or even
N <: Universe#Needle
unless you want to permit needles beyond one single universe
And while my example is very simplified, I have some rather messy code because of this
but if you have a combine method on Needle, you can write n1.combine(n2) directly, no?
Main point being I have multiple types belonging to a single
Universe and I'd like a method aware of that fact, able to operate on these types and return U#Something without needing to give it U.
In our case, the universe is a trait with multiple subtraits and in the end singleton objects inheriting from those. On the top level, all types are abstract and they become more specific along the way. There's no natural place within the universe to place many methods, unfortunately. And having the code spread throughout multiple packages also make things worse (e.g. one place where the methods are replaced by mocked ones).
I'll try to come up with a better test case demonstrating my issues more specifically
Is there any particular reason why this compiles
object ChainedConversions1 {
given implicitLength as Conversion[String, Int] = _.length
given implicitLengths[A](using ev: Conversion[A, Int]) as Conversion[Seq[A], Seq[Int]] = _.map(ev)
val strings: Seq[String] = Seq("", "a", "xyz")
val lengths: Seq[Int] = strings
}but this doesn't
object ChainedConversions2 {
implicit val implicitLength: Conversion[String, Int] = _.length
implicit def implicitLengths[A](implicit ev: Conversion[A, Int]): Conversion[Seq[A], Seq[Int]] = _.map(ev)
val strings: Seq[String] = Seq("", "a", "xyz")
val lengths: Seq[Int] = strings
}?
Main point being I have multiple types belonging to a single
Universeand I'd like a method aware of that fact, able to operate on these types and returnU#Somethingwithout needing to give itU.
There is no good approach in Dotty if you need to bundle multiple type members. You can only resort to restating multiple type constructor parameters, like
// Scala 2
trait Space[D <: Space[D]] {
type Point <: PointLike
type HyperCube <: HyperCubeLike
}
def foo[D <: Space[D]](p: D#Point, c: D#HyperCube) = ???// Scala 3
trait Space[P, H]
def foo[P <: PointLike, H <: HyperCubeLike](p: P, c: H) = ???but as soon as these types need to be matched to each other, you know need an instance of Space:
def foo[P <: PointLike, H <: HyperCubeLike](p: P, c: H)(implicit space: Space[P, H]) = ???
in my experience, if you have been using type projections, you need to apply a major reworking of your project to make it elegant again in Scala 3 (even more work if you want it still to cross-build against Scala 2), although it's doable.