Imported From: https://issues.scala-lang.org/browse/SI-6217?orig=1
Reporter: @paulp

@paulp said:
Jira is turning underscore-root-underscore into italics, which I'm sure is obvious, but anyway.

_root_

@adriaanm said:
Unassigning and rescheduling to M6 as previous deadline was missed.

@paulp said:
Maybe I misunderstand why this was given the label "error-messages" but this isn't about error messages. Perhaps an example is needed where it DOES compile but should certainly NOT compile.

package p {
  package _root_ {
    package scala {
      sealed trait Option[+T] { def isEmpty = false ; def donkey = 5 }
      final case class None[T]() extends Option[T] { def get: T = null.asInstanceOf[T] }
      final case class Some[T](x: T) extends Option[T] { }
    }
  }
}
// Meanwhile, in some other file
package p {
  object Test {
    import _root_.scala.Option
    def f[T](x: Option[T]) = x.donkey
  }
}

There is no "donkey" method on root .scala.Option. If root is to behave like any other relative package, then there is quite literally no reason for it to exist.

And conversely, this does NOT compile, but certainly SHOULD. root.scala.Option does have a "get" method.

package p {
  object Test2 {
    import _root_.scala.Option
    def f[T](x: Option[T]) = x.get
    // ./a.scala:18: error: value get is not a member of p._root_.scala.Option[T]
    //     def f[T](x: Option[T]) = x.get
    //                                ^
    // one error found
  }
}

@adriaanm said (edited on Feb 19, 2014 6:54:52 AM UTC):
I co-opted the label to group my fixes that introduce new errors (as opposed to those that change the behavior of normal/successful compilation). Sorry about the confusion

@adriaanm said (edited on Feb 20, 2014 5:33:06 AM UTC):
deprecated in: scala/scala#3565

@adriaanm said:
This patch does not go far enough, I know. Not sure if we should push this all the way to all identifier names.
As a follow-up, I'm considering hard-wiring root in an import to the root package, and disallowing it as a nested name.

@paulp said:
Noting for the record that the patch didn't wind up going even as far as not far enough: it didn't survive the review process. So as of scala 2.12.1 you can still name a package _root_ and it will subvert any _root_ referencing imports, with no warnings (even under -Xfuture.)

@dwijnand said:
I was thinking about this issue today too for some reason.

I wonder what you think: one could argue that you must know what you're doing if you're defining you're own \_root\_, and perhaps it being definable is a handy last resort?

@paulp said:
"You" can't rely on knowing what "you" are doing because there's no reason to expect the value of these two "you"s to coincide.

If packages had been defined up front to be relative to an abstract root, and there were some facility for controlling where that root is, that could be useful - albeit impractical on the jvm, which doesn't offer any way to virtualize packages short of bytecode rewriting. But the whole reason people use _root_ is they want to know what they're getting. It's explicitly NOT a virtual path.

It's in the specifiction: "The special predefined name _root_ refers to the outermost root package which contains all top-level packages."

@jvican has taken an interest in this recently

Yes. Making _root_ a keyword is the way to fix this issue IMO, since the word is already a standard. I'll put up a SIP about it.

The PR just enforces that import _root_.blah.blah means the root package always, and warns if there is a badly named symbol in scope.

Hopefully this averts enshrining _root_ as a keyword. Because then it would sit in the front of the spec and we'd have to look at it all the time. As it is, the homely identifier can sit in the back with other miscellany, not quite as forgotten as the chapter on XML syntax, but willing on occasion to step out and perform a humble duty when needed, before returning to that quiet if lonely place under the jeers of onlookers.

Is there any reason that a package should ever be named _root_?
It seems to me that special semantics at the start of the import statement is the wrong way to go, and to do so should be illegal
i.e.
import _root_.foo is always foo in the root package
import a._root_.foo should not compile
package _root_ should not compile

personally I would prefer the denotation of the root package not to be a legal character sequence for a package, and more obvious to the eye, e.g.

import /foo means from the root
import foo means not from root

but that is probably not achievable any more

@mkeskells In case you missed this https://contributors.scala-lang.org/t/proposed-syntax-for-root/1035

This PR would be the minimally useful warning only, in lieu of possible future syntaxes. Disallowing _root_ in some contexts is a good job for a linter.

@mkeskells your example is already illegal:

scala 2.13.0-M5> :pa
// Entering paste mode (ctrl-D to finish)

package p { object X }
package q { package p { class C { import _root_.p ; def f = p.X } } }

// Exiting paste mode, now interpreting.


                 package q { package p { class C { import _root_.p ; def f = p.X } } }
                                                          ^
<pastie>:2: error: _root_ cannot be imported
There were compilation errors!

I haven't excavated the why, although import _root_._ comes to mind. Note that this example wouldn't work anyway, as the import cannot shadow the enclosing p. It could shadow other imports, though.

@jvican I didn't know about that - looks good
@som-snytt - to clarify - (I hadn't realised that there was additional special casing on the special casing!)
import _root_.foo.bar is always bar in the foo package
import a._root_.foo should not compile
package _root_ should not compile

I wonder what havoc val _root_ : Int = 0 would have
or def _root_ : String
or type aliases and generic parameters
…

Instead lets make the root, in whatever form not a legal identifier!

To summarize the compromise, _root_ is a soft keyword as lead element of a qualifier; a warning is emitted if it "shadows" an ordinary _root_ in scope. That covers the use case and the gotcha. Any further tightening of screws could be taken to the SIP committee.