Skip to content

Move scala.util.Try and scala.util.Either to scala package. #11268

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

Closed
He-Pin opened this issue Nov 22, 2018 · 7 comments
Closed

Move scala.util.Try and scala.util.Either to scala package. #11268

He-Pin opened this issue Nov 22, 2018 · 7 comments
Labels
Milestone

Comments

@He-Pin
Copy link
Contributor

He-Pin commented Nov 22, 2018

Problem

Currently, these standard types are not top level and live in scala.util.* package. They should live in the top level.

Perposal

Move scala.util.Try and scala.util.Either to scala package,and annotation type alias in scala.util's package object to keep code compile,until we decide what's next move.

@He-Pin
Copy link
Contributor Author

He-Pin commented Nov 22, 2018

Also refs :scala/scala-dev#323

@dwijnand
Copy link
Member

dwijnand commented Nov 22, 2018

They should live in the top level.

Why?

Note that Either is already aliased in the scala package object (and Try isn't).

(edit: there's some discussion on this in scala/scala#7425)

@He-Pin
Copy link
Contributor Author

He-Pin commented Nov 22, 2018

@dwijnand I first came out with this idea and there is some discussion in scala/scala#5677 too.

scala.util (Try and Either move to the scala package)

I think these common types live in scala.util seems a little wired and especially there are many other not that much common sibling types live there.

@He-Pin
Copy link
Contributor Author

He-Pin commented Nov 22, 2018

BTW, there is https://github.com/vavr-io/vavr/tree/master/vavr/src/main/java/io/vavr/control which mostly alias with scala's type layout, cc @danieldietrich .

@som-snytt
Copy link

I think you mean scala.util.chaining._. I feel like I'm not living as well as I ought.

Now there is -Yimports:scala.util,scala.util.chaining which at least takes the sting out of REPL sessions.

@SethTisue
Copy link
Member

perhaps we could have made a different decision here initially, but I don't see good cost/benefit in changing it now

@som-snytt
Copy link

som-snytt commented Nov 1, 2023

As mentioned, discussion on PRs:
scala/scala#7425
scala/scala#7549

The latter unmerged PR represents consensus opinion, the unmerged will of the people. (scala.Try, scala.Try.Success, etc)

Counterfactual 2.13:
scala/scala#7425 (comment)

Also reduced ambition of library reducing diet, so "eliminate scala.util" is not in play:
scala/scala#5830

To coin a phrase,

we've run out of time in the 2.13 cycle — let's pick this up again for 2.14

Also Seth:

I'm convinced (by Seb and Nth) that this should wait for 2.14 and be part of a package of related changes rather happening independently.

Scala 3 is picking up steam on library changes, Result type.

There are related issues in Scala 3 about namespace for annotations.

@som-snytt som-snytt closed this as not planned Won't fix, can't repro, duplicate, stale Nov 1, 2023
@SethTisue SethTisue added this to the 3.x milestone Nov 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants