Skip to content

Add guidance on how to migrate scala.Seq #1326

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.

Sign up for GitHub

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

Merged
merged 6 commits into from
May 21, 2019
Merged

Add guidance on how to migrate scala.Seq #1326

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
2d8f8e5
Add guidance on how to migrate scala.Seq
eed3si9n May 10, 2019
8178166
Update _overviews/core/collections-migration-213.md
eed3si9n May 10, 2019
54b38f7
Update _overviews/core/collections-migration-213.md
eed3si9n May 10, 2019
6c56623
Update _overviews/core/collections-migration-213.md
eed3si9n May 10, 2019
2b4de2d
reflect review comments
eed3si9n May 20, 2019
cc9b455
scala.IndexedSeq too
eed3si9n May 20, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Update _overviews/core/collections-migration-213.md 
Co-Authored-By: Dale Wijnand <[email protected]>
  • Loading branch information
@eed3si9n @dwijnand
eed3si9n and dwijnand authored May 10, 2019
commit 6c566237690ef8948d619fea97ab91e96cbc18fc
2 changes: 1 addition & 1 deletion _overviews/core/collections-migration-213.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ In Scala 2.13 `scala.Seq[+A]` is an alias for `scala.collection.immutable.Seq[A]

If you're making an application, and simply migrating a Scala 2.12 code base to 2.13, it might be ok to keep using `scala.Seq` in your code.
Copy link
Contributor

Choose a reason for hiding this comment

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

This sounds like "keep using scala.Seq" should be the safe and simple option. I'd argue it's the opposite (unless your code happens to just work out of the box). In a complex codebase the simplest way forward is to change all references from scala.Seq to scala.collection.Seq and possibly insert toSeq calls where necessary. This is easy to do and will cross-compile on 2.12 without any changes in semantics.

Switching your own codebase from scala.collection.Seq to scala.immutable.Seq is the more advanced refactoring. In many cases it may have been the intention all along, so it makes sense to do it. It also avoids unnecessary copying when varargs are involved, but it's much harder to get right consistently in a large codebase.

Copy link
Member Author

Choose a reason for hiding this comment

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

Interesting. I'll mention recommendation to use scala.collection.Seq first then.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've added this in 2b4de2d.


If you're making a library intended to be used by other programmers, then using `scala.Seq` or vararg is going to be a breaking change in the API semantics. For example, if there was a function `def orderFood(order: Seq[Order]): Seq[Food]`, previously the library user would have been able to pass in an array of `Order`, but it won't work for 2.13.
If you're making a library intended to be used by other programmers, then using `scala.Seq` or varargs is going to be a breaking change in the API semantics. For example, if there was a function `def orderFood(order: Seq[Order]): Seq[Food]`, previously the library user would have been able to pass in an array of `Order`, but it won't work for 2.13.

- if you cross build with Scala 2.12 and want to maintain the API semantics for 2.13 version of your library, or
- if your library users frequently uses mutable collections such as `Array`
Copy link
Contributor

Choose a reason for hiding this comment

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

If code has been optimized to the point that you build an array instead of a regular collection, you're probably okay calling unsafeWrapArray, so it will still work with immutable varargs.

Copy link
Member Author

Choose a reason for hiding this comment

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

Arrays might come up simply as Java API that you provide as a subset of API.

Expand Down