toString ugliness

[Jarrett Billingsley]

On Sun, Dec 7, 2008 at 5:54 PM, Sergey Gromov <snake.scaly at gmail.com> wrote:
> 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.
>

Sorry.