------- Additional Comments From bangerth at dealii dot org 2005-08-12 04:05
-------
We're already at comment 85 in this PR, so this is definitely going to be my
last message.
While I sympathize with your desire to have a better error message, you seem
not to understand the implications of what you ask us to do. First, ADL
(Koenig lookup) is meant particularly to allow separation of names into
different namespaces, even though it allows for lookup of names across
namespaces. Consider this example:
-----------------------
// this is provided by the compiler:
namespace std {
template <typename T> void swap (T &,T &);
template <typename I> void bubble_sort (I &i1, I &i2) {
//bubble sort is implemented using swap(*i1, *i2)
}
// user code
namespace User {
class MyClass {...};
void swap (MyClass &, MyClass &) { user's implementation }
}
void main () {
std::vector<User::MyClass> v;
std::bubble_sort (v.begin(), v.end());
}
--------------------------
If it weren't for the name lookup rules that people complain about, then the
user defined
User::swap would never be called from inside std::bubble_sort; rather, you
would only ever get the
default std::swap, which would most likely not what you wanted. See the
problem?
In this example, you definitely do want ADL to work as it is supposed to,
but in the example used in this PR you don't. That's not consistent. It
would also not be very helpful to print a warning message to the screen
saying "hey, you may have wanted std::swap, but I picked User::swap anyway",
which would be the exact opposite of what you would want in the case you
present in this PR.
So your second solution was to ask that functions that don't compile properly
to simply be dropped from name lookup. Now, that's getting really messy:
---------------------------
int f(int i) {
do_something();
// oops, forgot return value -- compiler error
}
int g(int i) {
return f(i);
}
int h(int i) {
return g(i);
}
int h(double) {
return 1;
}
int main () {
h(1);
}
----------------------
What the user clearly wanted was to call h(int). However, h(int) calls a
function that has a user error -- oops. So f() and g() don't compile, should
h(int) be dropped from the overload list (without an error, as per your
suggestion), and h(double) be used with the standard conversion of the
argument '1' from int to double?
So, in neither case is changing the rules of the language a very good choice,
which is exactly why Gaby and I claim that there is no defect in the standard:
everything else one could possible come up with is even more completely
ununderstandable.
I hope this explains why we don't want to change the compiler to do something
different than what the standard prescribes -- because we're reasonably sure
that the standard wouldn't follow our precedent and we'd be eternally
incompatible after that.
The question remains whether we can do anything about the weird error message
one gets with code like yours. That it isn't very helpful is completely
undisputed, but that doesn't mean that anyone has an idea of how to improve
it.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
