Remove the helpers in scala.deriving.

[sjrd]

Draft PR for now to see what breaks in the community build.

[sjrd]

The community build says that two projects are affected: scodec and upickle. This fits my earlier expectations that the members here are fairly specific to deserializers.

---

To follow up on our meeting:

There are two more-or-less separate things here:

• ArrayProduct and EmptyProduct on the one hand, which IIUC were controversial but not too controversial.
• productElement, which was pretty controversial.

ArrayProduct and EmptyProduct are exclusively used as arguments to Mirror.Product.fromProduct. If we want to bless ArrayProduct and EmptyProduct as a good way to create a Product to give to fromProduct, then I would suggest that we instead add a method fromArray in Mirror.Product. It can be implemented entirely in the library (it doesn't need code generation):

    /** The Mirror for a product type */
    trait Product extends Mirror {

      /** Create a new instance of type `T` with elements taken from product `p`. */
      def fromProduct(p: scala.Product): MirroredMonoType

      /** Create a new instance of type `T` with elements taken from the array `elems`. */
      def fromArray(elems: Array[AnyRef]): MirroredMonoType =
        fromProduct(new Product {
          def canEqual(that: Any): Boolean = true
          def productArity: Int = elems.length
          def productElement(n: Int): Any = elems(n)
        })
    }

There is then no need for overriding more stuff from Product, as fromProduct only calls productElement anyway.

That said, why are we blessing Arrays over other sequences? Why not accept all kinds of Seqs, for example? Blessing Arrays seems very ad hoc to me.

---

For productElement, only scodec uses it. upickle uses v.asInstanceOf[Product].productIterator instead.

[smarter]

So productElement hides two casts: one to Product and one to the result type, but is the first cast actually needed? Can't we statically know that the thing we're dealing with is a Product and not just an Any ? If we can't then how can we use productElement safely in the first place? If we can then there's already a productElement method on Product, so this method just hides one cast which doesn't seem worth it.

[sjrd]

Yes, I also had that reasoning. I couldn't wrap my head around how either typeclass-derivation3 or scodec know that it is always a Product. It's used for example here:
https://github.com/lampepfl/dotty/blob/375de664073752eacfd631c9aee8a6cf98722422/tests/run/typeclass-derivation3.scala#L102
at which point it comes either from
https://github.com/lampepfl/dotty/blob/375de664073752eacfd631c9aee8a6cf98722422/tests/run/typeclass-derivation3.scala#L112
or
https://github.com/lampepfl/dotty/blob/375de664073752eacfd631c9aee8a6cf98722422/tests/run/typeclass-derivation3.scala#L162
In the second case it seems plausible that we know x: T to be a Product, although we cannot statically know it, because we got a ProductOf[T]. But even that is not clear when the ProductOf is a Mirror.SingletonProxy. But if having a ProductOf[T] is supposed to be a static guarantee that any x: T is a Product, we could define the following in Mirror.Product:

def asProduct(x: MirroredMonoType): Product = x.asInstanceOf[Product]

or even better, we could refine MirroredMonoType to have that as a static guarantee!

type MirroredMonoType <: Product

In the first case (in pickleCases), this does not work, because we don't even have a static proof that x is an alt to begin with. So I'm not sure what to do.

[smarter]

type MirroredMonoType <: Product

@milessabin ^ Do you think that makes sense?

[sjrd]

Since it looks like we're going to release an M2, I opened #10436 which deprecates the helpers, so that we can more easily remove them in RC1. I have also improved the replacements in the tests, compared to this PR. IMO the replacements are better than using the helpers, at this point.

[sjrd]

Superseded by #10830