RFC: remove `pub use` globs

[pnkfelix]

A recent chat I had with pcwalton led me to believe that many of the difficulties we have with globs in use declarations would be resolved if we simply restricted globs solely to imports, i.e. removed glob re-exports via pub use.

Removing pub use globs would imply that when rustc looks at the text of a module, it can locally determine all of the names that it exports. I think this would enable us to make a much simpler resolve algorithm: one pass to associate each module with the set of names it exports, and then a second pass to wire up the glob imports. (It still doesn't necessarily know which of the type/value namespaces the imported/exported names belong to, so resolve still remains non-trivial, but I think that's okay.)

This is meant as an alternative more-conservative option to #11825. In particular, Servo's use-case as documented by jack should continue to function under this plan, if I'm correct in inferring that the auto-generated code-bindings are solely creating imports.

(globs are feature-guarded for 1.0, so choosing a strategy here need not block the release. But it would probably make people more comfortable knowing how drastic a change to globs we might make.)

(I have been careful in my weasel wording above not to claim that all problems with globs stem from pub use alone, since bugs like #3352 do not even use pub use. But I suspect such bugs are artifacts of an complicated implementation strategy necessitated by pub use, and so I still think this route is worth considering.)

---

I will admit up front: glob imports are not a must-have feature for me; I'd be okay if #11825 landed instead of this approach. But I do think there is value in providing a way for people who want to play with some library to snag all of the functionality it provides trivially, especially for humans who learn via play.

[pnkfelix]

@metajack can you confirm (or counter) my hypothesis above that removing pub use would be compatible with Servo's use case?

[jdm]

Servo actually has at least two uses of pub use globs: http://mxr.mozilla.org/servo/source/src/components/script/script.rc#45

[metajack]

@jdm Could we remove those easily?

[jdm]

It would certainly be unpleasant, and I may even have added it to avoid some sort of circular dependency. I don't quite recall now.

[pnkfelix]

I would have assumed that given the option of removing all uses of globs, versus removing solely pub use globs, that the latter would be the far more attractive option in most projects. But perhaps I am mistaken.

(edit: I speak solely in terms of pain of doing the transformation; I am not speaking on the quality of the code after the transformation, since one can reasonably claim that a codebase with no globs of any kind is easier to work with. Not that I am claiming that... :) )

[nikomatsakis]

+1

[flaper87]

FWIW, I like this proposal.

[brson]

+1.

After removing globs from the code base there are a few use cases left where they are nice, particularly prelude injection. We need an answer for how the prelude works for 1.0.

Nominating.

[Valloric]

This sounds like a very reasonable proposal. I'm against glob imports for production code, but for tests they're great (e.g. pulling in all the names of the module you are testing). Re-exporting everything from a different module sounds like a recipe for disaster on the user-facing side even if it worked correctly in the compiler.

+1 for preventing people from shooting themselves in the foot.

[emberian]

gl-rs uses these, but it's automatically generated, we can make long lists of reexports with ease.

[pnkfelix]

Globs are already feature-gated, but there is an important use-case for them (or at least non pub-use globs) in the prelude.

P-backcompat-lang, 1.0. (Borderline, could be P-high.)