Skip to content
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

Simplify imports #442

Closed
adriaanm opened this issue Nov 21, 2017 · 5 comments
Closed

Simplify imports #442

adriaanm opened this issue Nov 21, 2017 · 5 comments

Comments

@adriaanm
Copy link
Contributor

We still need to be able to import from stable prefixes, like class members, local vals or arguments, but maybe we can simplify top-level imports? Should they always start at the root? Maybe other imports should not be considered when importing there?

(These are some pretty vague ideas. The goal of the simplification would be for simpler tooling and faster compilation.)

@adriaanm adriaanm added this to the 2.14 milestone Nov 21, 2017
@olafurpg
Copy link

Here is a fairly recent discussion on syntax for imports: https://contributors.scala-lang.org/t/proposed-syntax-for--root-/1035/60

In summary: requiring top-level imports to start from _root_ would break many people's habits for questionable gains.

Even if you assume imports are fully qualified, it's still not possible for syntactic tools organize them due to shadowing from wildcard imports.

As a tooling author, I would propose instead to add an additional feature to imports: support arbitrary nesting for grouped imports

import _root_.{
  a._
  a.b
  c.{d => e}
  k._
  ...
}

The desugaring should expand the importees of the same group in lexical order. Project that use this feature could benefit from being able to sort imports with syntactic tools like scalafmt.

@dwijnand
Copy link
Member

One change to importing that I want to propose is that wildcard imports don't import sub-packages. For instance import scala._ should import scala.Int, but not scala.collection.

@som-snytt
Copy link

This may illustrate @dwijnand 's point, or maybe something else:

package scala
package tools
package nsc
package doc
package html
package page

import base._
import base.comment._
[snip]
import model._
import model.diagram._
import diagram._

/*
src/scaladoc/scala/tools/nsc/doc/doclet
src/scaladoc/scala/tools/nsc/doc/base
src/scaladoc/scala/tools/nsc/doc/base/comment
src/scaladoc/scala/tools/nsc/doc/html
src/scaladoc/scala/tools/nsc/doc/html/page
src/scaladoc/scala/tools/nsc/doc/html/page/diagram
src/scaladoc/scala/tools/nsc/doc/html/resource
src/scaladoc/scala/tools/nsc/doc/html/resource/lib
src/scaladoc/scala/tools/nsc/doc/model
src/scaladoc/scala/tools/nsc/doc/model/diagram
 */

This stopped working when I fixed wildcard imports. Or maybe I broke them. But because model._ imports model.diagram, the subsequent diagram._ does not mean page.diagram._.

A wildcard import has higher precedence than the diagram package made available by package page but defined in a different file.

Although not importing package names with wildcard would behave like the previous incorrect behavior, there's something wrong with enabling this confused and confusing style of imports.

I can kind of see that the intuition here was: import from this path added to one of my package statements. That is, pretend wildcard doesn't select packages and that sort of works.

@SethTisue
Copy link
Member

this would need to happen in Scala 3 before we could consider any Scala 2 changes

@SethTisue SethTisue closed this as not planned Won't fix, can't repro, duplicate, stale Jan 23, 2023
@som-snytt
Copy link

This was on my mind the other day because Dale commented something of the form

import collection.mutable, mutable.ListBuffer

and odersky replied he had to try it to see if it worked.

It's a favorite idiom of mine, and I checked for usages in the repo, which were mostly test code.

So, it's a handy idiom but indicative of the failure to reform import syntax despite various bandied words about it.

There is not an obvious best way forward, and possibly all the options are complexifications.

The title of this ticket ought to be, Simplify [sic] imports.

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

No branches or pull requests

5 participants