When I used C++, my habit was to put #include at the top and using in the function that actually used the thing. This tells you the module-level dependencies up front, and the term-level dependencies near the use site, so it’s superficially the same as having a required top-level import in addition to local imports.
What I recall is that in practice I rarely looked at the headers unless I needed to refresh my memory of the dependencies or add a new one, so they might as well have been at the bottom of the file instead of in the way all the time.
OCaml allows a local open of modules, seemingly quite similar to some of the things being discussed here, so mentioning it because it’s relevant both in terms of comparing the feature set and also as a real-world example of how well this sort of thing works in practice and of how widely it’s used.
Thanks to everyone for the feedback on the LocalImports proposal so far. Over the past few weeks I’ve been going over the discussion, exploring related proposals from the past, and trying to make sense of it all. During this time I’ve come up with a separate proposal called Contexts that addresses the same concerns as LocalImports, and more.
The idea for it was inspired by other proposals like LocalModules and Namespaces, a 10+ year old r/haskell thread, and the discussion that was had here. It is still pretty rough, but I will continue to polish it. I read and appreciate all feedback you take the time to provide.
I am not dropping LocalImports. Just proposing an alternative based on what I know now.
Rust has this restriction, no orphan instances, but does not seem to suffer from it. But then Cargo has great support for feature flags, so library authors generally aren’t reticent to add a feature flag like serde to add optional support serde’s Serialize/Deserialize traits.