On Thursday, 21 February 2013 at 04:07:46 UTC, Steven Schveighoffer wrote:
> On Wed, 20 Feb 2013 21:50:01 -0500, deadalnix <deadalnix@gmail.com> wrote:
>
>> On Wednesday, 20 February 2013 at 13:42:48 UTC, Steven Schveighoffer wrote:
>>> On Wed, 20 Feb 2013 01:00:00 -0500, deadalnix <deadalnix@gmail.com> wrote:
>>>
>>>> As discussed previously, I really wonder hy a const and non const version of a function can exists in a first place. What problem does it solve that isn't better solved by inout ?
>>>
>>> const(T) and T are different types.  Saying you can overload on types, unless they just vary by const is a special case that I don't think is worth adding.
>>>
>>
>> Explain me how the hell you overload on implicit parameter types ?
>
> A method is simply a function that takes a hidden parameter of an object or struct.
>
> Really, a method with a signature Obj.foo() is a function with a signature foo(Obj this)
>
> A const method Obj.foo() const is a function with a signature foo(const(Obj) this)
>
> So it's equivalent to saying you can overload:
>
> foo(int *x)
> foo(const(int) *x)
>
> To disallow this would be unnecessarily restrictive.
>

That is called avoiding the question.

On Thu, 21 Feb 2013 00:20:36 -0500, deadalnix <deadalnix@gmail.com> wrote:

> On Thursday, 21 February 2013 at 04:07:46 UTC, Steven Schveighoffer wrote:
>> On Wed, 20 Feb 2013 21:50:01 -0500, deadalnix <deadalnix@gmail.com> wrote:

>>> Explain me how the hell you overload on implicit parameter types ?
>>
>> A method is simply a function that takes a hidden parameter of an object or struct.
>>
>> Really, a method with a signature Obj.foo() is a function with a signature foo(Obj this)
>>
>> A const method Obj.foo() const is a function with a signature foo(const(Obj) this)
>>
>> So it's equivalent to saying you can overload:
>>
>> foo(int *x)
>> foo(const(int) *x)
>>
>> To disallow this would be unnecessarily restrictive.
>>
>
> That is called avoiding the question.

I guess it's called not understanding the question?

-Steve

On Thursday, 21 February 2013 at 14:17:16 UTC, Steven Schveighoffer wrote:
>>>> Explain me how the hell you overload on implicit parameter types ?
>>>
>>> A method is simply a function that takes a hidden parameter of an object or struct.
>>>
>>> Really, a method with a signature Obj.foo() is a function with a signature foo(Obj this)
>>>
>>> A const method Obj.foo() const is a function with a signature foo(const(Obj) this)
>>>
>>> So it's equivalent to saying you can overload:
>>>
>>> foo(int *x)
>>> foo(const(int) *x)
>>>
>>> To disallow this would be unnecessarily restrictive.
>>>
>>
>> That is called avoiding the question.
>
> I guess it's called not understanding the question?
>

The question is how do you overload function on the hidden parameter. The answer, we both know it is that you can't.

You say that this is is just like a regular function but this is in fact very different. You have virtual dispatch and overriding capabilities in case of methods. And combined with the capability of overload on const, this create a whole new set of problems.

The principal one being :

class A {
    void foo() {}
}

class B {
    override void foo() const {}
}

Add a const foo method to A, and B;foo don't overload the same method anymore.

2013/2/23 deadalnix <deadalnix@gmail.com>

> class A {
>     void foo() {}
> }
>
> class B {
>     override void foo() const {}
> }
>
> Add a const foo method to A, and B;foo don't overload the same method anymore.
>

B.foo overrides A.foo. It is properly allowed as a particular case in contravariant parameter type.

Kenji Hara

On Friday, 22 February 2013 at 15:15:02 UTC, kenji hara wrote:
> 2013/2/23 deadalnix <deadalnix@gmail.com>
>
>> class A {
>>     void foo() {}
>> }
>>
>> class B {
>>     override void foo() const {}
>> }
>>
>> Add a const foo method to A, and B;foo don't overload the same method
>> anymore.
>>
>
> B.foo overrides A.foo. It is properly allowed as a particular case in
> contravariant parameter type.
>
> Kenji Hara

I know that. Now if you add a const version of foo in A, B;foo don't override the same method anymore.

2013/2/23 deadalnix <deadalnix@gmail.com>

> On Friday, 22 February 2013 at 15:15:02 UTC, kenji hara wrote:
>
>> 2013/2/23 deadalnix <deadalnix@gmail.com>
>>
>>  class A {
>>>     void foo() {}
>>> }
>>>
>>> class B {
>>>     override void foo() const {}
>>> }
>>>
>>> Add a const foo method to A, and B;foo don't overload the same method anymore.
>>>
>>>
>> B.foo overrides A.foo. It is properly allowed as a particular case in contravariant parameter type.
>>
>> Kenji Hara
>>
>
> I know that. Now if you add a const version of foo in A, B;foo don't override the same method anymore.
>

Yes, then the B's definition should raise "mutable A.foo() is not
overridden but hidden in B" (but doesn't because of bug 8366).

Kenji Hara

On Fri, 22 Feb 2013 10:04:23 -0500, deadalnix <deadalnix@gmail.com> wrote:

> On Thursday, 21 February 2013 at 14:17:16 UTC, Steven Schveighoffer wrote:
>>>>> Explain me how the hell you overload on implicit parameter types ?
>>>>
>>>> A method is simply a function that takes a hidden parameter of an object or struct.
>>>>
>>>> Really, a method with a signature Obj.foo() is a function with a signature foo(Obj this)
>>>>
>>>> A const method Obj.foo() const is a function with a signature foo(const(Obj) this)
>>>>
>>>> So it's equivalent to saying you can overload:
>>>>
>>>> foo(int *x)
>>>> foo(const(int) *x)
>>>>
>>>> To disallow this would be unnecessarily restrictive.
>>>>
>>>
>>> That is called avoiding the question.
>>
>> I guess it's called not understanding the question?
>>
>
> The question is how do you overload function on the hidden parameter. The answer, we both know it is that you can't.

I just demonstrated that you can.  Here it is spelled out:

class A {
   void foo() {}
   void foo() const {}
}

> You say that this is is just like a regular function but this is in fact very different. You have virtual dispatch and overriding capabilities in case of methods. And combined with the capability of overload on const, this create a whole new set of problems.
>
> The principal one being :
>
> class A {
>      void foo() {}
> }
>
> class B {
>      override void foo() const {}
> }
>
> Add a const foo method to A, and B;foo don't overload the same method anymore.

That's because you have changed the overload set, and this is a case of overriding with contravariance.

I can do the same trick without const:

class X {}
class Y : X {}

class A {
   void foo(Y y) {}
}

class B {
   override void foo(X x) {}
}

Now, add the function void foo(X x) into class A, and B.foo doesn't override the same function any more.

Note, this code doesn't compile, because contravariance is only allowed on the 'this' parameter.  Not sure why.

BTW, you are misusing overload to mean override (or specifically overriding with contravariance?), and I understand the mistake now, this is why I was confused on your original comment.

-Steve

On Fri, 22 Feb 2013 11:09:31 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

>
> class X {}
> class Y : X {}
>
> class A {
>     void foo(Y y) {}
> }
>
> class B {
>     override void foo(X x) {}
> }

Oops, should be class B : A

-Steve

On Friday, 22 February 2013 at 15:32:42 UTC, kenji hara wrote:
> Yes, then the B's definition should raise "mutable A.foo() is not
> overridden but hidden in B" (but doesn't because of bug 8366).
>

I don't really understand why adding a special case for something that has no real use case.

2013/2/23 deadalnix <deadalnix@gmail.com>

> On Friday, 22 February 2013 at 15:32:42 UTC, kenji hara wrote:
>
>> Yes, then the B's definition should raise "mutable A.foo() is not
>> overridden but hidden in B" (but doesn't because of bug 8366).
>>
>>
> I don't really understand why adding a special case for something that has no real use case.
>

In old age, it had thrown HiddenFuncError in runtime, and some years ago,
it had been changed to compile-time error.
It is one of design in D to avoid unintended method hiding issue.

Kenji Hara