[ 
https://issues.apache.org/jira/browse/SPARK-27681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837854#comment-16837854
 ] 

Sean Owen commented on SPARK-27681:
-----------------------------------

I don't think it would change source compatibility; {{scala.Seq}} is just a 
type def for {{scala.collection.Seq}}, so it's a no-op w.r.t. the source and 
binary. Or am I missing something i really should know about how type def work? 
certainly wouldn't be worth breaking source compatibility; the point if 
anything would be to keep a little binary compatibility. If we're not concerned 
about Scala binary compatibility, I'm imagining maybe the corner case of a Java 
lib that refers to {{Seq}} in its API? that's a weak reason. At best I would 
consider this later.

Counter-argument: we should be changing the API to explicitly return immutable 
Seqs anyway; that's the motivation for the Scala 2.13 change to begin with.

There's another wrinkle here which I don't think we can help anyway. varargs 
methods in Scala will change their signature as they are implemented with Seq. 
That we can't control.

> Use scala.collection.Seq explicitly instead of scala.Seq alias
> --------------------------------------------------------------
>
>                 Key: SPARK-27681
>                 URL: https://issues.apache.org/jira/browse/SPARK-27681
>             Project: Spark
>          Issue Type: Sub-task
>          Components: ML, MLlib, Spark Core, SQL, Structured Streaming
>    Affects Versions: 3.0.0
>            Reporter: Sean Owen
>            Assignee: Sean Owen
>            Priority: Major
>
> {{scala.Seq}} is widely used in the code, and is an alias for 
> {{scala.collection.Seq}} in Scala 2.12. It will become an alias for 
> {{scala.collection.immutable.Seq}} in Scala 2.13. To avoid API changes, we 
> should simply explicit import and use {{scala.collection.Seq}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Reply via email to