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.
For instance, the opDispatch, which would allow to do this:

struct Library
{
    void* handle;

    static Library opDispatch(string name)() @property
    {
        auto namez = toUTFz!(const(wchar)*)(name);
        return LoadLibraryW(namez); // of course, it would cache the
loaded library handle in an AA or something
    }

    void* opDispatch(string name)() @property
    {
        auto namez = toUTFz!(const(char)*)(name);
        return GetProcAddress(handle, namez);
    }

    unittest
    {
        alias extern(Windows) void* function(in char*) GetModuleHandleA_t;
        auto GetModuleHandleA =
cast(GetModuleHandleA_t)Library.Kernel32.GetModuleHandleA
        assert(GetModuleHandleA !is null);
        assert(GetModuleHandleA(null) == 0x40000000);
    }
}

The only way to achieve the same result now is to introduce a dummy structure, which would be returned by the static opDispatch, which in turn would implement the non-static opDispatch. This is bad, because it's tedious and has run-time footprint.

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?

-- 
Bye,
Gor Gyolchanyan.

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

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@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.