Closed adriaanm closed 1 year ago
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.
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
.
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.
this would need to happen in Scala 3 before we could consider any Scala 2 changes
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
.
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.)