https://issues.dlang.org/show_bug.cgi?id=3345

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unspecified                 |D2

--

https://issues.dlang.org/show_bug.cgi?id=3345

Alex <sascha.orlov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sascha.orlov@gmail.com

--

https://issues.dlang.org/show_bug.cgi?id=3345

Mike Parker <aldacron@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldacron@gmail.com

--- Comment #5 from Mike Parker <aldacron@gmail.com> ---
This recently turned up from a user in Discord, affecting opCall:

struct S {

    void opCall(int x) {
    }

    static S opCall(int x) {
        return S.init;
    }
}

int main() {
    auto s = S(1);
    s(1);

    return 0;
}

--

https://issues.dlang.org/show_bug.cgi?id=3345

--- Comment #6 from Alex <sascha.orlov@gmail.com> ---
struct S {

    void opCall(int x) {
    }

    static S opCall(int x) {
        return S.init;
    }
}

int main() {
    auto s = S(1);
    s(1);

    return 0;
}

yields:
source/app.d(13,15): Error: need `this` for `opCall` of type `void(int x)`
dmd failed with exit code 1.

whereas after interchanging the functions inside the struct:

struct S {

    static S opCall(int x) {
        return S.init;
    }

    void opCall(int x) {
    }

}

int main() {
    auto s = S(1);
    s(1);

    return 0;
}

yields:
source/app.d(13,15): Error: `app.S.opCall` called with argument types `(int)`
matches both:
source/app.d(3,14):     `app.S.opCall(int x)`
and:
source/app.d(7,10):     `app.S.opCall(int x)`
dmd failed with exit code 1.

At least on an Intel Mac 10.15.7.

--

https://issues.dlang.org/show_bug.cgi?id=3345

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #7 from RazvanN <razvan.nitu1305@gmail.com> ---

(In reply to Andrei Alexandrescu from comment #0)
> Consider:
> 
> class Widget {
>     int fun() { return 1; }
>     static int fun() { return 2; }
> }
> 
> void main() {
>     writeln(Widget.fun());       // should print 2
>     writeln((new Widget).fun()); // should print 1
> }
> 
> This should work. Otherwise there is no way to explain how .classinfo works in terms of D facilities.

Currently, the staticness of a function is not considered when doing overload resolution. What the compiler does is simply check whether the function needs a this pointer or not **after** it has resolved it. This is an elegant solution and it greatly simplifies the implementation since you don't have to take staticness into account when matching the overloads. Of course, the trade off is that overloading static and non-static member functions does not work well.

I would argue that mixing static and non-static functions in the same overload set is bad practice and therefore should be discouraged. Since we can call static member functions on both instances and non-instances, why would we need something like this bug report proposes?

I suggest that we dissallow overloading static and non-static functions. It makes for an easy implementation and clear spec at the cost of having the user rename a function.

--

https://issues.dlang.org/show_bug.cgi?id=3345

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com

--- Comment #8 from Basile-z <b2.temp@gmx.com> ---
considering that the `this` parameter is not part of the signature it's indeed reasonable not to support static and nonstatic in the same set.

```
struct S
{
    void v1(){}
    static void v2(){}

    alias Fun = void();

    static assert(is(typeof(v1) == Fun));
    static assert(is(typeof(v2) == Fun));
}
```

--

https://issues.dlang.org/show_bug.cgi?id=3345

Max Samukha <maxsamukha@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxsamukha@gmail.com

--- Comment #9 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to RazvanN from comment #7)

> 
> I suggest that we dissallow overloading static and non-static functions. It makes for an easy implementation and clear spec at the cost of having the user rename a function.

That would be a major breaking change.

--

https://issues.dlang.org/show_bug.cgi?id=3345

--- Comment #10 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to Basile-z from comment #8)
> considering that the `this` parameter is not part of the signature it's indeed reasonable not to support static and nonstatic in the same set.
> 
> ```
> struct S
> {
>     void v1(){}
>     static void v2(){}
> 
>     alias Fun = void();
> 
>     static assert(is(typeof(v1) == Fun));
>     static assert(is(typeof(v2) == Fun));
> }
> ```

I wouldn't use the broken type system as a rationale. Static and non-static function types should have never been equal.

--

https://issues.dlang.org/show_bug.cgi?id=3345

--- Comment #11 from Basile-z <b2.temp@gmx.com> ---
(In reply to Max Samukha from comment #10)
> (In reply to Basile-z from comment #8)
> > considering that the `this` parameter is not part of the signature it's indeed reasonable not to support static and nonstatic in the same set.
> > 
> I wouldn't use the broken type system as a rationale. Static and non-static function types should have never been equal.

I'm not 100% sure of what I will say but I would say that it's not really "broken", rather that "it's pragmatically adapted to closures". You see, a kind of tradeoff.

--

https://issues.dlang.org/show_bug.cgi?id=3345

--- Comment #12 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to Basile-z from comment #11)

> I'm not 100% sure of what I will say but I would say that it's not really "broken", rather that "it's pragmatically adapted to closures". You see, a kind of tradeoff.

I understand it was an attempt at pragmatism, but the type system is still broken.

struct S {
    void foo() {
        x = 1;
    }

    int x;
}

void main() {
    void function() f = &S.foo; // this means "broken"
    f(); // bang
}

--