static vs non-static method overloading

[Jacob Carlborg]

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