Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow customizing root imports #474
Summary of the discussion in scala/scala#5350:
It also sounds like an
referenced this issue
Feb 26, 2018
referenced this issue
Mar 1, 2018
I'd like to stir up some discussion about the
As the feature is envisioned now, I can imagine scenarios in which updating to a binary-compatible library could break lots of source code. Even changing the order of the
What is the feature really trying to solve? Does it aim to provide a nice way to import things at use-site without the user knowing much about the organisation of the library?
If this is the case, it's worth researching how we could address this problem with external tooling. For example, what if library authors could write typechecked templates (via a macro or a compiler plugin) and then have IDEs automatically import them? What if the recommended imports (that would be represented via
Anytime you use import some.lib._ what is in scope is already determined by some.lib and can change when upgrading versions. This doesn’t feel like a new risk to me for most use cases. It would allow a library to restructure it’s internals without causing a breakage or needing a user side migration which seems like as much a benefit as a risk. Hopefully others will chime in but to my mind the two important usages of an export type functionality are:
Personally this also changes how I organize code. I end up putting logic in my companions that I would not otherwise just to get the “free import” from the companion object.
Sure, but the point I'm trying to make is that in the
My simple implementation (simplementation) is over on scala/scala#5339.
All it supports is
That PR implements the level 4 name binding rule; to make that work usefully, it also introduces a "rule" that preamble imports are also level 4 precedence. That means they can't introduce ambiguities in user code, which is how it works now.
On another ticket or PR, @fommil mentions that the typelevel feature can introduce ambiguities.
The intuition is that if I can't see it in my code, make it a lower precedence so it only pops up when I need it. Otherwise, the rules for shadowing are unchanged. One case where it matters is for symbols in my package but not defined in my file: ordinary imports (at level 2 or 3) would create an ambiguity.
Level 2 and 3 correspond to specific and wildcard imports; but preamble imports are always wildcard and always level 4.