On 2012-04-04 19:48:32 +0000, "Steven Schveighoffer"
<[email protected]> said:
On Wed, 04 Apr 2012 14:03:07 -0400, Timon Gehr <[email protected]> wrote:
No symbol is resolved until semantic, but I don't think hiding the
module/package symbol if any clashing symbol in the module/any
subpackage exists is a satisfactory solution.
Then we must come up with a way to hide the submodules of a virtual module.
I tried this, which fails on the current compiler:
import x;
int x;
So it seems we have two choices here:
1. DIP16 needs to get more complex to make package submodules not
accesible as individual modules.
2. Start contextually interpreting identifiers at least in the case of
modules vs. non-modules.
I'd suggest option 2 allows for better backwards compatibility and more
flexibility.
I don't think option 2 is realistic (see my other post).
I don't think option 1 is an improvement over what we have. I mean, if
you're going to hide the submodules, what is the benefit compared to
just using a different package name for the implementation modules? You
can already refactor std.algorithm this way with no change in the
compiler:
module std.algorithm;
public import std.algorithm_impl.sort;
public import std.algorithm_impl.map;
public import std.algorithm_impl.blah_blah_blah;
…
If we add a language feature, it should be an noticeable improvement
over this situation.
I think we need a third option.
Here's an idea: we could allow modules having a single symbol with the
same name as the module to behave as if they were the symbol itself,
just like templates behaves. For instance:
module std.algorithm.sort;
void sort(int[] t);
Now you can import std.algorithm.sort and then use the
std.algorithm.sort fully qualified name as if it was a function, even
though it's the module name (std.algorithm.sort.sort would be the
function's name).
Or maybe we could just allow "alias sort this" at module level? Or is
it allowed already?
--
Michel Fortin
[email protected]
http://michelf.com/
