RFC: requiring leading :: on use declarations

[pnkfelix]

I have found it confusing that a path in an expression context uses relative lookup (and you specify absolute paths via a leading ::), while the paths in the use declarations all use absolute lookup (and one needs to use a leading self or super to get relative lookup).

It might be easily to digest these forms if the absolute paths of use declarations required leading ::.

Update: glaebhoerl 's comment below implicitly points out that another alternative would be to use relative referencing without leading self in use declarations. This avoids the wall of :: problem (assuming that one starts off with use ::crate for each external crate of interest; presumably use ::std would be in the prelude), but it may introduce other usability issues that we currently side-step.

[brson]

It would be nice to clear this up, but leading :: is ugly and I don't really want to see a wall of them on every source file. Maybe we can rethink the syntax for absolute paths to make it more palatable.

[kbarros]

I was confused by this as well.

[glaebhoerl]

Just out of curiosity: could someone elaborate about the particular technical problems that would be posed by allowing use decls with relative lookup (i.e. use foo::bar; use bar::baz;), or refer me to existing material about it?

To lead off with a question: I assume one issue is that if there's also a top-level bar, then in the example above, which one does use bar::baz; refer to? If that's the case, why doesn't the same thing we do elsewhere, where things declared or imported in inner modules shadow those from outer modules (so it would choose the bar imported from foo), also work here? Is this the main issue? Are there other issues?

[pnkfelix]

@glaebhoerl I suspect @pcwalton knows better here, but I am not sure there are many technical problems, assuming e.g. that each use is resolved relative solely to the use decls that precede it (i.e. later ones are not in scope), and assuming that once you make use decls use relative resolution, that absolute lookups would be written with a leading ::. That last detail sounds like it would resolve the top-level bar example you provided. (Presumably the prelude would include a use ::std so that all the existing use std::foo::bar would continue to work.)

The bigger issue is whether we would want to go down the road of relative lookup in use decls. E.g. I am not eager to have to scan through all of the preceding use decls in order to interpret the one I am currently looking at. And it is likewise nice that I can easily cut-and-paste use decls into other contexts within a crate. But maybe these are minor issues that I could solve independently (or just use leading :: throughout the use decls in my own code...)

[glaebhoerl]

@pnkfelix Thanks. To be clear, I'm not necessarily proposing that we allow it, I'm just interested in the background w.r.t. why things are the way they are. You might be correct that even from an ergonomic perspective it wouldn't be desirable.

The only difference it would make compared to what we have now is whether relative paths need to be prefixed with self::, right?

[pnkfelix]

@glaebhoerl Oh, you are correct. I had incorrectly thought that use self::... would only look at items defined in self, not at the imports of self. But this was, as I said, incorrect.

[glaebhoerl]

@pnkfelix Funny, I only realized the same thing halfway through my last comment, based on your comment in the OP. I thought I was the one behind the curve. :)

[nikomatsakis]

One reason -- which is not technical -- is that it was really hard
to tell what was going on in the "old days", when imports could be
relative. There were various instances of people not being able to
tell where an import was coming from.

That said, I don't have a clear understanding of what the limits
are. I believe the current system still suffers from some ambiguous or
bizarre situations and I don't know that removing relative use
statements made any such situations "go away" entirely (though it may
have). I vaguely recall though that it was possible to rewrite at
least some of the bad examples in the current syntax.

[pnkfelix]

After discussion at meeting, decided that none of the alternatives here are all that attractive. (Though I was intrigued by @nikomatsakis 's proposal of "try relative, then fall back on absolute" for resolution in non-use contexts, which is like what Java and others do.)

Anyway, closing; we should instead put in better compiler diagnostics (e.g. checking if abs/rel would work instead on error, and then presenting an error message explaining this language detail) to help new users get over this initial speed-bump.