https://d.puremagic.com/issues/show_bug.cgi?id=11845

           Summary: selective (and renamed) imports clash with local
                    symbols
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: monarchdodra@gmail.com


--- Comment #0 from monarchdodra@gmail.com 2013-12-30 00:58:32 PST ---
//----
import foo = std.algorithm : splitter;

void splitter(){};

void main()
{
}
//----
Error: function main.splitter conflicts with alias main.splitter at main.d(1)

I don't see why there is a conflict here. Both should be able to coexist.

Marking as blocker as this is getting in the way of correctly fixing 6730: We need to have a deprecated import alias co-exist with existing functions...

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11845


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |INVALID


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2013-12-31 13:58:57 PST ---
This is the way it is designed to work, it is not a bug. Altering this behavior will, of course, potentially break significant existing code.

> We need to have a deprecated import alias co-exist with existing functions...

Such would be a significant design change, and would need a DIP.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11845



--- Comment #2 from monarchdodra@gmail.com 2013-12-31 14:16:35 PST ---
(In reply to comment #1)
> This is the way it is designed to work, it is not a bug.

I'd understand an *ambiguity*, but a straight up conflict? It basically means that if I need to import a specific symbol in a module, I'm *banned* from declaring an *overload* myself?

That seems strange, since simply declaring all the functions in the same module remains legal. The functions are *mutually* exclusive. Technically, there isn't even any ambiduity :/

In particular, in my original report, I did a *renamed* import: From my module's point of view, there is only "foo". Why is "splitter" conflicting with "foo"?

> Altering this behavior
> will, of course, potentially break significant existing code.

I challenge you to come up with an example where this would break existing code. I don't see it.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11845


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #3 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2014-01-03 00:01:22 PST ---
(In reply to comment #2)
> In particular, in my original report, I did a *renamed* import: From my module's point of view, there is only "foo". Why is "splitter" conflicting with "foo"?

I think you imported that wrong, it should be:

import std.algorithm : foo = splitter;

and not:

import foo = std.algorithm : splitter;

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------