DMD 1.035 and 2.019 releases

[Max Samukha]

On Thu, 04 Sep 2008 14:37:27 -0700, Walter Bright
<newshound1 at digitalmars.com> wrote:

>Bill Baxter wrote:
>> On Fri, Sep 5, 2008 at 6:20 AM, Pablo Ripolles <in-call at gmx.net> wrote:
>>> Walter Bright Wrote:
>>>
>>> Hence, since there is a clear connection between the first point and the last point, why should the ctor substitute (or *override* as it has been used by you before) other than the static opCall mentioned in the last point?
>>>
>>> My experiments with real code and the last compiler version show that once there is present a ctor it even invalidates the possibility of accessing the *non-static* opCall to use a plain instance of that struct as if it were a function.  Is that the expected behavior?
>> 
>> If that's really the case with the latest D2 then that is odd.  In C++
>> there isn't even a static opCall, only the non-static variety, but it
>> works just fine in conjunction with constructors. Functor  structs and
>> structs with constructors should not be mutually exclusive.  Kill off
>> static opCall, fine, but don't kill instance opCall.  That's one step
>> forward one step back.
>
>The non-static opCall should work fine.

Only the parameterless non-static opCall seem to work:

    struct S
    {
        this(int x)
        {
        }

        void opCall()
        {
        }
    }

    auto s = S(1);
    s(); // ok

In other cases the compiler ignores the opCall and tries to use the
constructor:

    struct S
    {
        this(int x)
        {
        }

        void opCall(int y)
        {
        }
    }

    auto s = S(1);
    s(1); //  Error: * has no effect in expression


Also, when opCall is a better match:

    struct S
    {
        this(int x)
        {
        }

        void opCall(int y, int z)
        {
        }
    }

    auto s = S(1);
    s(1, 2); //  Error: this(int x) does not match parameter types