[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

["adah at netstd dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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