------- Additional Comments From adah at netstd dot com 2005-08-12 05:12
-------
I am not sure whether we can finish here (not to challenge you, but that I am
still a little misunderstood). See below (for pure technical discussions, and
just to reply to you).
(In reply to comment #90)
> 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
On the contrary, I do.
> (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:
[Example snipped]
> 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
It is consistent.
What I thought when I entered the discussion here was that ADL should work but
the instantiation error should remove it from the candidate list (e.g. to
extend SFINAE). So I did think ADL worked here, and there was no consistency.
Herb Sutter's opinion (N1792) is a little different. He thinks that ADL should
not work in the OP's example, because distance is simply not an `interface' of
std::vector (technically, instead of from human eyes). But it is also self-
consistent.
> 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.
This was not what I used to want. But since I learnt that the future was still
undecided which way the committe would take to solve this issue, it is safer to
have a better diagnostice message *now*.
> 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?
This can be a valid point. Practically it is a little difficult to
differentiate an instantiation error from a program error.
Though, Sutter's suggestion is still a way to go.
> 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 think the above discussion is enough and I do not need to add comments
here? :-)
> 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.
I stated long ago (several days indeed) that this could be of lower priority,
but it needs to be agreed on and added to a to-do list. Before your message I
had not seen a single agreement, but only flames.
> W.
Yongwei
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
