July 29, 2021
https://issues.dlang.org/show_bug.cgi?id=3345

Richard Cattermole <alphaglosined@gmail.com> changed:

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

--- Comment #13 from Richard Cattermole <alphaglosined@gmail.com> ---
Add @safe to your main function.

onlineapp.d(11): Error: `this` reference necessary to take address of member
`foo` in `@safe` function `main`
onlineapp.d(12): Error: `@safe` function `D main` cannot call `@system`
function pointer `f`

--
July 30, 2021
https://issues.dlang.org/show_bug.cgi?id=3345

--- Comment #14 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to Richard Cattermole from comment #13)
> Add @safe to your main function.
> 
> onlineapp.d(11): Error: `this` reference necessary to take address of member
> `foo` in `@safe` function `main`
> onlineapp.d(12): Error: `@safe` function `D main` cannot call `@system`
> function pointer `f`

Right, passing the context via the void* pointer makes a non-static function type unsafe. It is still a distinct type from the corresponding static function type because of that additional parameter.

I hope a variant of DIP1011 eventually gets through, but DIP1011 doesn't talk about fixing types of member functions and closures. It does propose to fix delegates' funcptr by introducing a properly typed alias.

--
July 30, 2021
https://issues.dlang.org/show_bug.cgi?id=3345

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #15 from Walter Bright <bugzilla@digitalmars.com> ---
> Otherwise there is no way to explain how .classinfo works in terms of D facilities.

It is explained by if the member function is static, the 'this' reference is used for its type.

    writeln(Widget.fun());       // Widget is a type
    writeln((new Widget).fun()); // (new Widget) gives the type

This is so that member functions that don't need the `this` reference can still work fine if the `this` reference is provided.

This explains the overloading behavior. The compiler and language is working as designed.

For code like this:

    int fun() { return 1; }
    static int fun() { return 2; }

I cannot understand what purpose there is for writing such code.

--
July 30, 2021
https://issues.dlang.org/show_bug.cgi?id=3345

--- Comment #16 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to Walter Bright from comment #15)
> > Otherwise there is no way to explain how .classinfo works in terms of D facilities.
> 
> It is explained by if the member function is static, the 'this' reference is used for its type.
> 
>     writeln(Widget.fun());       // Widget is a type
>     writeln((new Widget).fun()); // (new Widget) gives the type
> 
> This is so that member functions that don't need the `this` reference can still work fine if the `this` reference is provided.
> 
> This explains the overloading behavior. The compiler and language is working as designed.
> 
> For code like this:
> 
>     int fun() { return 1; }
>     static int fun() { return 2; }
> 
> I cannot understand what purpose there is for writing such code.

But having different error messages depending on the order of declarations is definitely wrong.

--
July 30, 2021
https://issues.dlang.org/show_bug.cgi?id=3345

--- Comment #17 from Walter Bright <bugzilla@digitalmars.com> ---
> But having different error messages depending on the order of declarations is definitely wrong.

Probably, but it's a minor issue, as both messages are correct.

--
July 30, 2021
https://issues.dlang.org/show_bug.cgi?id=3345

--- Comment #18 from RazvanN <razvan.nitu1305@gmail.com> ---
Do you suggest we close this as invalid?

--
July 30, 2021
https://issues.dlang.org/show_bug.cgi?id=3345

--- Comment #19 from Walter Bright <bugzilla@digitalmars.com> ---
Not yet, because the spec neglects to mention this behavior. I'll see about fixing that tomorrow.

https://dlang.org/spec/function.html#function-overloading

--
July 30, 2021
https://issues.dlang.org/show_bug.cgi?id=3345

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec
          Component|dmd                         |dlang.org
           Hardware|Other                       |All
                 OS|Linux                       |All

--
July 30, 2021
https://issues.dlang.org/show_bug.cgi?id=3345

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #20 from Dlang Bot <dlang-bot@dlang.rocks> ---
@WalterBright created dlang/dlang.org pull request #3080 "fix Issue 3345: Static and nonstatic methods with the same name shoul…" fixing this issue:

- fix Issue 3345: Static and nonstatic methods with teh same name should be allowed

https://github.com/dlang/dlang.org/pull/3080

--
August 02, 2021
https://issues.dlang.org/show_bug.cgi?id=3345

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #21 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/dlang.org pull request #3080 "fix Issue 3345: Static and nonstatic methods with the same name shoul…" was merged into master:

- 4bb31c3d5533cf048856bd1ea92f664b22bf9d25 by Walter Bright:
  fix Issue 3345: Static and nonstatic methods with teh same name should be
allowed

https://github.com/dlang/dlang.org/pull/3080

--