scala / scala-dev

Scala 2 team issues. Not for user-facing bugs or directly actionable user-facing improvements. For build/test/infra and for longer-term planning and idea tracking. Our bug tracker is at https://github.com/scala/bug/issues
Apache License 2.0
130 stars 14 forks source link

Simplify imports #442

Closed adriaanm closed 1 year ago

adriaanm commented 6 years ago

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.)

olafurpg commented 6 years 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.

dwijnand commented 6 years ago

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 commented 6 years ago

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 commented 1 year ago

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

som-snytt commented 1 year ago

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.