toString ugliness

[Sergey Gromov]

Sat, 6 Dec 2008 13:04:56 -0500, Jarrett Billingsley wrote:

> On Sat, Dec 6, 2008 at 12:11 PM, Jerry <jlquinn at optonline.net> wrote:
>> Jarrett Billingsley Wrote:
>>
>>> On Sat, Dec 6, 2008 at 11:21 AM, Jerry <jlquinn at optonline.net> 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.