static vs non-static method overloading

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Wed Apr 18 09:33:39 PDT 2012


Voted up (as well as the related enhancement request).
Please vote up, so it gets fixed ASAP.

On Wed, Apr 18, 2012 at 8:26 PM, Jacob Carlborg <doob at me.com> wrote:
> On 2012-04-18 12:17, Gor Gyolchanyan wrote:
>>
>> Time and time again I've stumbled upon this crippling limitation,
>> which gives an ambiguity error if you define and refer to this:
>>
>> struct Jolly
>> {
>>     static Jolly opCall()
>>     {
>>         // to simulate a default constructor
>>     }
>>
>>     real opCall()
>>     {
>>         // makes it jolly and returns the jolliness factor
>>     }
>> }
>>
>> If you try to "construct" a Jolly, you get an ambiguity error and if
>> you hack yourself an instance of it, you'll get the same ambiguity
>> error if you try to get the jolliness factor.
>> This particular case can be circumvented by replacing the non-static
>> opCall with something like makeJolly, but there are cases, when this
>> won't work.
>
>
>
>> Is this supposed to be like this or is it a bug? If it's a bug, what
>> are the plans (if any) to fix it?
>>
>
> I would want to overload on static as well. It has already been reported:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=3345
>
> --
> /Jacob Carlborg



-- 
Bye,
Gor Gyolchanyan.


More information about the Digitalmars-d mailing list