Thread overview
[Issue 18289] static function and access frame
Jan 24, 2018
Mike Franklin
Dec 17, 2022
Iain Buclaw
May 05, 2023
RazvanN
January 24, 2018
https://issues.dlang.org/show_bug.cgi?id=18289

Mike Franklin <slavo5150@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
                 CC|                            |slavo5150@yahoo.com

--
January 28, 2018
https://issues.dlang.org/show_bug.cgi?id=18289

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--
May 12, 2019
https://issues.dlang.org/show_bug.cgi?id=18289

Aurelien Fredouelle <aurelien.fredouelle+dlang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aurelien.fredouelle+dlang@g
                   |                            |mail.com

--
May 13, 2019
https://issues.dlang.org/show_bug.cgi?id=18289

--- Comment #1 from Aurelien Fredouelle <aurelien.fredouelle+dlang@gmail.com> ---
Ran into the same issue, here is some extra sample code to better understand the problem:

template A(alias fun)
{
  void A() {
    fun();
  }
}

struct B(alias fun)
{
  static void opCall() {
    fun();
  }
}

void foo() {}

void main() {

  static void bar() {}

  void hun() {}

  A!foo(); // OK
  B!foo(); // OK

  A!bar(); // OK
  B!bar(); // OK

  A!hun(); // OK
  B!hun(); // ERROR! static function app.main.B!(hun).B.opCall cannot access
frame of function D main
}

The issue happens when instantiating the templated struct with an object that lives on the stack of the calling function (such as the `hun` function). But it looks like this case is not so different from the previous one (`A!hun()`), using an eponymous function template rather than a struct with a static opCall. Is it really expected for one case to succeed and the other to fail?

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=18289

Iain Buclaw <ibuclaw@gdcproject.org> changed:

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

--
May 05, 2023
https://issues.dlang.org/show_bug.cgi?id=18289

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

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

--- Comment #2 from RazvanN <razvan.nitu1305@gmail.com> ---
This is not a bug. The alias parameter can be seen as a pointer that is stored inside the declaring struct. Since fun is static it should have no context pointer, therefore it cannot access the alias parameter.

> Is it really expected for one case to succeed and the other to fail?

Yes, because your opCall is static and cannot access anything in B's context. If you declare `A()` as static you will end up with the same error message.

--