www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11845] New: selective (and renamed) imports clash with local symbols

reply d-bugmail puremagic.com writes:
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



//----
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: -------
Dec 30 2013
next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Dec 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11845





 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: -------
Dec 31 2013
prev sibling parent d-bugmail puremagic.com writes:
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



00:01:22 PST ---

 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: -------
Jan 03 2014