Empty Tuple is not instance of Product

[letalvoj]

Minimized code w Output

scala> ().asInstanceOf[Tuple].isInstanceOf[Product]
val res5: Boolean = false

scala> (1,2,3).asInstanceOf[Tuple].isInstanceOf[Product]
val res6: Boolean = true

Expectation

I should be able to call ($m: Mirror.Product).fromProduct(()). Currently it's not possible due to the bug above.

[sjrd]

Unfortunately, as long as the empty tuple is undistinguishable from unit, this is unfixable. The instance of Unit cannot be an instance of Product, or any type of than AnyRef for that matter, as that would break the foundations of Scala.js.

[letalvoj]

@sjrd Well, I would be much more satisfiet if the behaviour was the following

().asInstanceOf[Tuple].isInstanceOf[Product] // true
().isInstanceOf[Product] // false

Because currently we can get a runtime error in a case like the following:

scala> val t:Tuple = ()
val t: Tuple = ()

scala> summon[Mirror.Of[...]].fromProduct(t.asInstanceOf)                   
java.lang.ClassCastException: class scala.runtime.BoxedUnit cannot be cast to class scala.Product (scala.runtime.BoxedUnit and scala.Product are in unnamed module of loader sbt.internal.classpath.ClassLoaderCache$Key$CachedClassLoader @37c469b4)

[sjrd]

@sjrd Well, I would be much more satisfiet if the behaviour was the following

().asInstanceOf[Tuple].isInstanceOf[Product] // true
().isInstanceOf[Product] // false

That would run contrary to a core expectation that asInstanceOf does not perform any conversion, and hence cannot change the nature of its argument, nor the result of subsequent type tests.

Because currently we can get a runtime error in a case like the following:

scala> val t:Tuple = ()
val t: Tuple = ()

scala> summon[Mirror.Of[...]].fromProduct(t.asInstanceOf)                   
java.lang.ClassCastException: class scala.runtime.BoxedUnit cannot be cast to class scala.Product (scala.runtime.BoxedUnit and scala.Product are in unnamed module of loader sbt.internal.classpath.ClassLoaderCache$Key$CachedClassLoader @37c469b4)

There's an asInstanceOf there, which happens not to be valid. It's expected that it would result in a CCE.

[letalvoj]

@sjrd Well, I would be much more satisfiet if the behaviour was the following

().asInstanceOf[Tuple].isInstanceOf[Product] // true
().isInstanceOf[Product] // false

That would run contrary to a core expectation that asInstanceOf does not perform any conversion, and hence cannot change the nature of its argument, nor the result of subsequent type tests.

I was aiming more to () being an instance of a different trait in different contexts. Sorry, should have been something more like

(():Tuple).isInstanceOf[Product] // true
(():Unit).isInstanceOf[Product] // false

Does it make more sense?

[sjrd]

I was aiming more to () being an instance of a different trait in different contexts. Sorry, should have been something more like

(():Tuple).isInstanceOf[Product] // true
(():Unit).isInstanceOf[Product] // false

Does it make more sense?

Ah sorry, I had completely misunderstood. Yes, that makes much more sense, and in principle I would like to see that happen. I am not sure what the ramifications of that would be, though. It might prove impractical, or prone to more dangerous warts.

[letalvoj]

Well, I checked how is it possible that shapeless-3 is not having issues with this feature and there is a custom ArrayProduct.

I suppose that this is a known feature which was widely discussed internally. There seem to be other related functionality in place.

scala> ((1,2):Tuple).isInstanceOf[Product]                                                                                                            
val res7: Boolean = true

scala> ((1,2):Tuple):Product
1 |((1,2):Tuple):Product
  | ^^^^^^^^^^^
  | Found:    Tuple
  | Required: Product

Anyway, I'd want to raise a concern about having inconsistencies such as ^^ in the type system. I'd expect to be able to execute the following statement ((1,2):Tuple):Product. Maybe it might be worth decoupling Unit from Tuple, either explicitly, or implicitly using an approach such as #9033 (comment)

[sjrd]

That's not an inconsistency. This happens all the time in all object-oriented type systems.

scala> trait A; trait B; class C extends A with B
trait A
trait B
class C

scala> (new C(): A).isInstanceOf[B]
val res0: Boolean = true

scala> (new C(): A): B
               ^
       error: type mismatch;
        found   : A
        required: B

[letalvoj]

@sjrd oh my... I did not know that Tuple itsef is not Product. Thanks for clarification.
https://github.com/lampepfl/dotty/blob/f807eee1a5c0a9c4b980926cc46bf490eb0740bc/library/src/scala/Tuple.scala#L7

That explains the behaviour but it is rather surprising to me. Since the trait is sealed, i.e. std lib has full control over it's instances, I can see only reason for it being the case and that's supporting the "Unit is not Product" edge case. Am I correct?

[sjrd]

That's correct.

[nicolasstucki]

Currently we define these types, which do not exist at runtime.

sealed trait Tuple extends Any { ... }
sealed trait NonEmptyTuple extends Tuple { ... }
sealed abstract class *:[+H, +T <: Tuple] extends NonEmptyTuple { ... }

All tuple types are made a subtype of *: and Unit is made a subtype of Tuple.

At runtime we use Tuple1 to Tuple22 if the size of the tuple fits, if it is larger we use TupleXXL, otherwise, if the tuple is empty we use ().

final class TupleXXL private (es: IArray[Object]) extends Product

The issue source of the issue is that Unit does not extend Product and therefore Tuple cannot extend Product. One would be tempted to extend Unit with Product but this would break fundamental assumptions on the Unit.

The solution is to simply define a proper Tuple0 that is a Product

object Tuple0 extends Product

The only reason we have not done this is to be able to use the syntax () in combination with *:.

val tup = 1 *: 2 *: () // equivalent to: (1, 2)
tup match
  case x *: y *: () => // equivalent to: case (x, y) =>
  case () => // no equivalent (or maybe using a training comma `(,)`)

We usually never create or match using *: if we know the size of the tuple as it is always longer and harder to read. Therefore the real reason to have () as an empty tuple right now is to be able to create and match against the empty tuple.