Sat, 6 Dec 2008 13:04:56 -0500, Jarrett Billingsley wrote: > On Sat, Dec 6, 2008 at 12:11 PM, Jerry <[EMAIL PROTECTED]> wrote: >> Jarrett Billingsley Wrote: >> >>> On Sat, Dec 6, 2008 at 11:21 AM, Jerry <[EMAIL PROTECTED]> wrote: >>> > toString() doesn't work inside a class member function. >>> > >>> > import std.string; >>> > class A { >>> > void f() { >>> > string s = toString(5); >>> > } >>> > } >>> > >>> > This errors with junk.d(19): function object.Object.toString () does not >>> > match parameter types (int) >>> > >>> > This is a nuisance and a wart (though not a bug per-se). >>> > >>> > If the language really can't handle distinguishing this.toString() from >>> > toString(int), then std.string.toString really should have a different >>> > name. >> >> As I'm thinking about this, why does this actually fail? The parameter >> doesn't match the prototype for this.toString(), so why not match against >> the global function? >> >> Is this due to the behavior that override solves? Would marking >> Object.toString() as override fix the problem? >> >> > > As far as I know, it's because D does not use ADL (argument-dependent > lookup). That is, it simply looks for the toString that is in the > nearest enclosing scope, and if it doesn't match - too bad. Compare > this behavior to C++, where it would then continue on, looking for a > definition of toString that does match.
Not correct. C++ uses the same rules to build overload sets as D. That is, a function declaration in an inner scope hides any function declarations with the same name in outer scopes. I /think/ there should be a good rationale behind this design. Actually, any declaration works like this. A variable declaration hides any declarations with the same name in the outer scopes. Probably functions follow this rule to make overloading more predictable.