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 <[email protected]> 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.
