digitalmars.D.bugs - [Issue 11845] New: selective (and renamed) imports clash with local symbols
- d-bugmail puremagic.com (28/28) Dec 30 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11845
- d-bugmail puremagic.com (14/15) Dec 31 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11845
- d-bugmail puremagic.com (17/20) Dec 31 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11845
- d-bugmail puremagic.com (14/17) Jan 03 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11845
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
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
https://d.puremagic.com/issues/show_bug.cgi?id=11845This 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
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