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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |razvan.nitu1305@gmail.com
         Resolution|---                         |WORKSFORME

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
I cannot reproduce this. The code compiles, runs and exits gracefully.

--

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

Max Samukha <maxsamukha@gmail.com> changed:

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

--- Comment #2 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to RazvanN from comment #1)
> I cannot reproduce this. The code compiles, runs and exits gracefully.

How does this even work? Implicitly binding the function pointers to `this` is an extremely confusing semantics. Rather than stacking yet another hack on top of the pile, we'd better fix the underlying issue, which is member functions having invalid types.

--

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

Salih Dincer <salihdb@hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |salihdb@hotmail.com

--- Comment #3 from Salih Dincer <salihdb@hotmail.com> ---
No problem:

alias T = string;
alias fun = T function();
template Fun(fun funA, fun funB)
{
  void print()
  {
    import std.stdio : writeln;
    funA().writeln;
    funB().writeln;
  }
}

template Hun()
{
  void print()
  {
    import std.stdio : writeln;
    foo().writeln;
    bar().writeln;
  }
}

struct S {
  //mixin Fun!(&foo, &bar);/*/
  mixin Hun;//*/

  T foo() => "First";
  T bar() => "Second";
}

void main()
{
  S s;
  s.print();
}

--

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

--- Comment #4 from Salih Dincer <salihdb@hotmail.com> ---
(In reply to Max Samukha from comment #2)
> ... stacking yet another hack
> on top of the pile, we'd better fix the underlying issue, which is member
> functions having invalid types.

You are right, because there is alias!

--

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

Max Samukha <maxsamukha@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #5 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to Salih Dincer from comment #4)

> You are right, because there is alias!

I am not sure what you mean exactly, but functions passed by alias are correctly rejected if they are used in a wrong context. Consider:

mixin template Template(void function() func1, alias func2) {
    static void foo() {
        func1(); // UB
        // func2(); // This fails to compile
    }
};

class SomeClass {

    int x;
    mixin Template!(&func23);

    void func23() {
        x = 1;
    }
}

void main() {
    SomeClass a = new SomeClass;
    a.foo();
    assert(a.x == 1); // Fails
}

I am reopening this. Local function types have been an embarrassment for decades and should be fixed.

--

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

--- Comment #6 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to Max Samukha from comment #5)


>     mixin Template!(&func23);

Should be `mixin Template!(&func23, func23);`

--

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

--- Comment #7 from RazvanN <razvan.nitu1305@gmail.com> ---
Well, what we are seeing here is just another manifestation of 3720: https://issues.dlang.org/show_bug.cgi?id=3720 . The underlying issue is that when you take the address of a member function that is not attached to an instance, the pointer of the function (in the .txt) section is returned. The type is not a delegate because it was intended to be used in conjunction with the .funcptr and .ptr properties of delegates (you can take the address of some delegate as a function pointer and set it as the funcptr of another delegate). I'm saying this is a good design, I am just stating what the situation is. In this context, the code compiles because the function are not using any instance members therefore the context pointer, even though it is garbage it is not used at all. If you add a member to the class and try to access it in those functions you will probably get a segfault.

I am inclined to close this as a dupe of 3720, as fixing that will most likely fix this case also.

--

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

--- Comment #8 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to RazvanN from comment #7)
> Well, what we are seeing here is just another manifestation of 3720: https://issues.dlang.org/show_bug.cgi?id=3720 .
> 
> I am inclined to close this as a dupe of 3720, as fixing that will most likely fix this case also.

Yes, I agree.

--

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |DUPLICATE

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


*** This issue has been marked as a duplicate of issue 3720 ***

--