Cant use compiletime.ops.any.== with String when type of a value

[bishabosha]

minimized code

scala> import compiletime.ops.any._

scala> summon["" == "" =:= true]                                                                                        
val res1: true =:= true = generalized constraint

scala> val t: "" == "" = true
1 |val t: "" == "" = true
  |       ^
  |       Type argument ("" : String) does not conform to upper bound AnyVal 
1 |val t: "" == "" = true
  |             ^
  |       Type argument ("" : String) does not conform to upper bound AnyVal 

expectation

EDIT: the second example behaves according to its definition of type ==[X <: AnyVal, Y <: AnyVal] <: Boolean. However it should behave like the first. The type signature should be changed so that t can be typed

[smarter]

Comparing string literals is a legitimate thing to do, so can't this be fixed by changing the signature of ==to type ==[X <: Singleton, Y <: Singleton] ?

[bishabosha]

what would you say for this case, is the left side of =:= meant to be reduced first?:

scala> import compiletime.ops.int._

scala> class Foo
// defined class Foo

scala> summon[Foo * Foo =:= 0]
1 |summon[Foo * Foo =:= 0]
  |                       ^
  |Cannot prove that Foo * Foo =:= (0 : Int)..
  |I found:
  |
  |    <:<.refl[Nothing]
  |
  |But method refl in object <:< does not match type Foo * Foo =:= (0 : Int).

[smarter]

Honestly no idea, but that's a separate problem from getting == to work with string which is what #8721 was about, and it was closed in favor of this issue.

[bishabosha]

updated the context

[MaximeKjaer]

Singleton might also be overly restrictive, as it then doesn't allow for String == String to be modeled. But it may allow for (String & Singleton) == (String & Singleton), so perhaps that's equivalent?

If the parameter type bounds change to Singleton, it could make sense to change the result type of the operation to Singleton as well (e.g. Boolean & Singleton for ==).

[smarter]

Yeah, so we could also just have no bounds at all if that's simpler.

[soronpo]

It's better to have no bounds at all in this context, or to change == from any package to string and int, etc. with the proper bounds. So we will have int.== and string.==.

[soronpo]

It is my intention to update the singleton-ops library to dotty, so it will take of combining generic == for all the various operation types using match type.

[MaximeKjaer]

Moving them to type-specific subpackages means that we lose the ability to do 1 == "1". I don't know how useful that is in the first place though, as you're guaranteed that constants of different types are not equal, so perhaps that's a trade-off worth making.

[MaximeKjaer]

I actually thought String would be a subtype of AnyVal when I wrote those bounds. So no type bounds is also fine by me. It would fit the package name of ops.any, and the semantics are preserved when you apply a compiletime op with something else than a primitive singleton type (i.e. the type is not folded in those cases).

[soronpo]

Moving them to type-specific subpackages means that we lose the ability to do 1 == "1"

I don't think that is useful, but again in singleton-ops I will be able to do

type ==[L, R] <: Boolean = (L, R) match {
  case (Int, Int) => int.==[L, R]
  case (String, String) => string.==[L, R]
  case (Int, String) => string.==[string.ToString[L], R]
}