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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eyal@weka.io

--- Comment #19 from RazvanN <razvan.nitu1305@gmail.com> ---
*** Issue 21862 has been marked as a duplicate of this issue. ***

--

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

--- Comment #20 from RazvanN <razvan.nitu1305@gmail.com> ---
*** Issue 17080 has been marked as a duplicate of this issue. ***

--

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

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

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

--- Comment #21 from RazvanN <razvan.nitu1305@gmail.com> ---
Raising severity for this issue as it is a long standing hole.

--

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tomer@weka.io

--- Comment #22 from RazvanN <razvan.nitu1305@gmail.com> ---
*** Issue 21195 has been marked as a duplicate of this issue. ***

--

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

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

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

--- Comment #23 from Dlang Bot <dlang-bot@dlang.rocks> ---
@RazvanN7 created dlang/dmd pull request #14688 "Fix Issue 3720 - Taking address of member functions possible without an instance" fixing this issue:

- Fix Issue 3720 - Taking address of member functions possible without an instance

https://github.com/dlang/dmd/pull/14688

--

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

--- Comment #24 from Bolpat <qs.il.paperinik@gmail.com> ---
@Zombine(In reply to ZombineDev from comment #18)
> […]
> 
> 2. After deprecation period is finished, reintroduce the &<AggregateType>.<memberFunction> but with different semantics: retunring a delegate with context pointer set to null.

Why? If I want a delegate with a null pointer context and member function
mfunc, today I can do
```d
alias T = the-aggregate-type;
auto dg = &(cast(T*)null).mfunc;
```
As an added benefit, it is absolutely clear what happens.

If that is not defined behavior because of supposed null pointer dereference, we can just make it a special-case and allow it.

--

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

dlang+issues@me.tracemymail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|dlang+issues@me.tracemymail |
                   |.com                        |

--

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

Max Samukha <maxsamukha@gmail.com> changed:

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

--- Comment #25 from Max Samukha <maxsamukha@gmail.com> ---
Everybody who actually tried to implement a reflection library in D would want local function (pointer) types to include the context pointer as an explicit parameter (as suggested here, for example https://github.com/dlang/dmd/pull/14688#issuecomment-1347358238).

--

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schuetzm@gmx.net

--- Comment #26 from RazvanN <razvan.nitu1305@gmail.com> ---
*** Issue 13850 has been marked as a duplicate of this issue. ***

--

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

--- Comment #27 from Bolpat <qs.il.paperinik@gmail.com> ---
Given
```d
struct T
{
    ref int memFunc(return ref int i) return @safe immutable { return i; }
}
```
I guess the only reasonable thing `typeof(&T.memFunc)` could be is:
```d
ref int function(return ref immutable T, return ref int i) @safe
```

We can argue about whether the `T` parameter must be `ref`, but unless we have a mechanism to express “bind by mutable reference irrespective of value category” (this is how member functions bind the `this` object) as a parameter storage class, the only option is `ref`. Copy isn’t an option, not all types are copyable. `in` isn’t an option because it makes mutable objects `const`.

DMD’s answer for `typeof(&T.memFunc)` is nonsense:
```d
ref int function(return ref int i) immutable return @safe
```

Both, `immutable` and `return` make no sense on a function pointer type and do not even parse.

--