DIP16: Transparently substitute module with package

[Jonathan M Davis]

On Friday, March 30, 2012 12:15:44 Brad Anderson wrote:
> On Fri, Mar 30, 2012 at 12:06 PM, Andrej Mitrovic <
> 
> andrej.mitrovich at gmail.com> wrote:
> > On 3/30/12, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> > > Destroy!
> > 
> > "That means a program that imports std.algorithm may use "std.sort"
> > for the symbol "std.algorithm.sort"."
> > 
> > That's quite interesting. Would that also mean that you could do:
> > import std.algorithm; // has indexOf
> > import std.string; // has indexOf
> > void main() {
> > 
> > string.indexOf("foo", "foo"); -> std.string.indexOf
> > 
> > }
> 
> I was actually kind of surprised when I found out this doesn't work. It
> seems so natural to resolve ambiguity using as little context as necessary.

It would certainly be desirable in some cases, but I believe that the reason 
that it doesn't work is due to the ambiguities that it would create. I'd have 
to go dig up old discussions on it though to remember all of the details.

alias is supposed to solve the problem, but it doesn't really work all that 
well for it, since private doesn't hide symbols, it only makes them 
inaccessible (just like with C++). So, creating aliases in a module causes 
problems in other modules that import that module, even if the aliases are 
private. There are definitely some folks pushing for private to actually start 
hiding symbols (IIRC, there's even a pull request for it), but I don't know 
what the odds of convincing Walter are. If/Once that happens, alias will 
actually become usable for this sort of situation, and the inability to do 
string.indexOf won't be as big a deal.

- Jonathan M Davis