Skip to content

Add implicit conversion from IArray to immutable.ArraySeq #11319

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

nicolasstucki
Copy link
Contributor

@nicolasstucki nicolasstucki commented Feb 4, 2021

Based on #11320
Part of #11298

@@ -273,6 +273,51 @@ object opaques:
extension [T](arr: IArray[T]) def zip[U: ClassTag](that: IArray[U]): IArray[(T, U)] =
genericArrayOps(arr).zip(that)
}

/** Conversion from IArray to immutable.ArraySeq */
given genericWrapIArray[T]: Conversion[IArray[T], scala.collection.immutable.ArraySeq[T]] =
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on https://github.com/scala/scala/blob/2.13.x/src/library/scala/Predef.scala#L544

Not sure if this is the best location for this conversion. We could also move it to Predef.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strange, it seems that implicit conversions have higher priority than extension methods. @odersky, is that the intended behaviour?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to add a DummyImplicit to make it work

@nicolasstucki nicolasstucki self-assigned this Feb 5, 2021
Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a conversion from IArray to Seq? I see three alternatives:

  1. No conversion, but add all Seq methods (including toSeq) as extension methods to IArray. The methods can be overloaded to specialize for primitive element types, just like the wrapArray conversions are specialized.
  2. An old style implicit conversion
  3. A new style Conversion instance.

I think I would go with (1). It's better not to introduce implicit conversions for new types. (2) is better than (3) since new style conversions warn at the use site which is definitely not what we want here. So new style conversions should not be used for extension methods.

I experimented with the idea of overloaded toSeq. It seems to be possible to do it if we use @targetName:

import annotation.targetName
case class IA[+X](xs: X*)

extension (x: IA[Int])
  @targetName("toIntSeq")
  def toSeqq: Seq[Int] = List(1, 2, 3, 4)
extension [T](x: IA[T])
  def toSeqq: Seq[T] = List()

def f[T](as: IA[T]) =
  val xs = IA(1, 2, 3)
  println(xs.toSeqq)
  println(as.toSeqq)

@main def Test =
  f(IA("a"))

Adding all the Seq methods as extension methods is a bit tedious. I have a branch that is already half way there.

I have another idea how we can avoid the repetition in the future: Allow export in extension blocks. But that is for after 3.0.

@sjrd
Copy link
Member

sjrd commented Feb 8, 2021

Why would we specialize all the extension methods of IArray when we don't do that for Array?

@odersky
Copy link
Contributor

odersky commented Feb 8, 2021

Why would we specialize all the extension methods of IArray when we don't do that for Array?

We only specialize toSeq which corresponds to the specialized implicit conversions from Array to ArraySeq. I.e. the Seq wrapper should not have to use reflection to access the array elements.

@nicolasstucki
Copy link
Contributor Author

I experimented with the idea of overloaded toSeq. It seems to be possible to do it if we use @TargetNAME:

We do not need to use @TargetNAME as the extension methods have the arrays in their signature and those be resolved as they are just arrays for the JVM. We already do that with apply and length.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants