------- Additional Comments From adah at netstd dot com 2005-08-11 02:01 ------- (In reply to comment #76) > Subject: Re: can't compile self defined void distance(std::vector<T>, std::vector<T>) > "adah at netstd dot com" <[EMAIL PROTECTED]> writes: > | Now to your point. Please notice that my current stance is not that > | GCC should fix this `bug'. I have stated it days ago. But the > | user's failure is really UNEXPECTED, and this is a PROBLEM. > Please, do consider that the outcome of this is the specification of > "argument dependent name lookup". It is the same rules that apply > whether the function is called "distance" or "freebies" and the > namespace is called "std" or "foobar". Just saying, "ah, this is std, > therefore the outcome is unexpected" is not sufficient. To > appreciate the issue and argue you NEED to understand the rules. > Furthermore, and more importantly, GCC bugzilla is the not the place > to record UNEXPECTED or PROBLEM with the C++ standard.
Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard is never considered a PRoblem at all? If it is, please show me where I can read it. > | To avoid this problem, a better diagnostic message should be > | emitted. Just try compiling the OP's program to see my point. > Just consider how you would formulate the rules for name lookup to > appreciate the point people are making here. There is no magic. We > don't have the keyword "readmymind". If the instantiation of a function (its body or its return type, arguments, etc.) fails during overload resolution, then the complete name of the function should be output. If this function is in some namespace and the original function call is not qualified, then an additional warning on argument- dependent lookup should be emitted. Simple rules. I do not think it is magic. Just that some contexts need to be remembered. > [...] > | I cannot help wondering why (though this might be better discussed > | on comp.std.c++: I do hope you can discuss there). IMHO, the > | current bahaviour is violating the rationale of the std namespace. > You seem to focuse on namespace std, without understanding that this > issue has nothing particular to do with std. Would have the issue > have been different if the namespace was called std? If you think > yes, then I suggest you give it more thoughts. No. If I put it simply, then this behaviour violates the rationale of namespaces. Please notice that I always consider it a problem in the C++ compiler (nothing to do with one specific namespace) instead of libstdc++. Again I can say yes. This problem is most likely encountered by a user using the std namespace. Logically, `violates the rationale of the std namespace' does not contradict `violates the rationale of namespaces'. However, on this point you are basically right. I should have expressed better. > [...] > | c) Failure to instantiate a template function should automatically remove it > | from the candidates of overload resolution. > If you want to modify standard rules, please, again take it to the > committee in charge of C++. > -- Gaby This is not the behaviour I am currently requesting. I just wanted to told Wolfgang there is a third way to `fix' the problem which I prefer better than his suggestions. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
