Bug 11845 – selective (and renamed) imports clash with local symbols

//---- 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...

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.

(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.

(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;