scala.compiletime.ops.long.S doesn't work

[unkarjedy]

Related #13400

Compiler version

3.3.1-RC4

Minimized code

@main def foo(): Unit =
  //This works:
  val value1: scala.compiletime.ops.int.S[0] = 1

  //This doesn't work:
  val value2: scala.compiletime.ops.long.S[0L] = 1L

Output

Compiler generates error for 1L:

Expectation

No compilation error.
Type scala.compiletime.ops.long.S[0L] should be equal to 1L

[unkarjedy]

JFTR previously found bug in a similar subsystem: #18340

[dwijnand]

Yeah, makes sense as https://github.com/lampepfl/dotty/blob/72f9d7afc3acfd8201e164da6608b99bb9218b64/compiler/src/dotty/tools/dotc/core/TypeComparer.scala#L1488

only considers ops.int, not also the equivalent in ops.long. Seems like a simple fix.

[soronpo]

Is there a reason to keep S[T] as a special case instead of changing it to S[T <: Int] = +[T, 1] and S[T <: Long] = +[T, 1L] accordingly? We might get some performance penalty for something that relies solely on S, but it seems weird to keep specialized now that have such a wide variety of operations.

[sjrd]

S[-1] is not defined, but +[-1, 1] =:= 0. So S is not a special-case of +[T, 1]. Also I think S[MaxValue] is not defined but +[MaxValue, 1] would be MinValue.

And then S needs to special-cased for match types anyway.

[soronpo]

@unkarjedy what was your actual use-case for this? I'm thinking of issuing a PR deprecating it instead of fixing it, since it was a mistake to create is in the first place, IMO (my mistake).

[dwijnand]

What's the mistake? Just unnecessary?

[soronpo]

Yeah, it does not make sense to have an incremental compiletime numbering until 2^64.

[soronpo]

FWIW, there is already a branch to fix this (no tests ATM), but I think it's better to deprecate it.
https://github.com/soronpo/dotty/tree/fix_longS