On Sun, Dec 7, 2008 at 5:54 PM, Sergey Gromov <[EMAIL PROTECTED]> wrote: > 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. >
Sorry.