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