Bug 14095 – explicitly exclude symbol from resolution consideration

There needs to be a mechanism for specifically excluding a particular symbol from resolution in a given scope. I've been struggling for months to chase std.array.array out of my codebase: I use a custom multidimensional array and, somehow, when I call .array on anything, std.array takes the call and subsequently fails to compile. My custom array isn't attempted, and no symbol conflict error is issued by the compiler. Sometimes .array will correctly route to my array, but its a coin toss. I suspect this has something to do with the longstanding import visibility bug, and I've been led to understand that fixing it is a massive and tricky undertaking, so until its solved, something like pragma (excludeSymbol, std.array.array); would be immensely helpful, if only as a stopgap measure.

I would point out that if the bug that's causing the problem is bug# 314, then I'm pretty sure that pragma(excludeSymbol, std.array.array) wouldn't work anyway, because it would be viewed as being a member of whatever module had the selective import rather than std.array. If something else is causing the problem, then maybe your suggestion would work. I don't know. Regardless, it would be easier to diagnose what's causing your problem if you provide a code sample which exhibited it. The fact that you're not seeing a symbol conflict definitely makes me wonder what's going on. Unless UFCS is involved, you'd normally end up with a symbol conflict, and UFCS favors member functions over free functions, so it's unlikely that that would cause a free function like std.array.array to be favored. It may be some bug in overload resolution. But if you provide code, then maybe we could actually figure out what you're running into - and it may or may not be a previously reported bug. In any case, as a workaround, IIRC, alias array = myarray.array; at the module level will fix the problem so that within the module, array refers to myarray.array. regardless of the imports. So, you should probably try that. Or you could just use static imports for everything, but that would be pretty annoying. Of course, an even easier alternative would simply be to rename your array function to something else, as annoying as that might be.

Yeah, I've finally rooted out the offending import, and the overloads are now routing correctly. Can't believe it took that long to find it, but either way I guess my report is invalid.