On Friday, March 30, 2012 12:15:44 Brad Anderson wrote:
> On Fri, Mar 30, 2012 at 12:06 PM, Andrej Mitrovic <
>
> andrej.mitrov...@gmail.com> wrote:
> > On 3/30/12, Andrei Alexandrescu <seewebsiteforem...@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
