December 05, 2017
https://issues.dlang.org/show_bug.cgi?id=3720

--- Comment #11 from Mike Franklin <slavo5150@yahoo.com> ---
A little more information about this issue and the test case:

struct S {
    int a;
    void fun()
    {
        this.a = 1;
    }
}

void main()
{
    auto fp = &S.fun;
    fp();
}

There may be 2 schools of thought on how this should behave:
(1) `auto fp = &S.fun;` is trying to get the address of a non-static function
through a type.  Instead, it can be argued that the programmer should have
written `S s; auto fp = &s.fun;` Notice the lower-case `s`.
(2)  `&S.fun` should return a `void function(S* s)` instead of a `void
function()`

If (1) were implemented the compiler would emit an error at `auto fp = &S.fun;` because it is trying get the address of a non-static `fun` through the type `S`.

If (2) were implemented the compiler would emit an error at `fp();` because a
context pointer was not supplied as an argument.  In other words it should be
`fp(&s)`.

--
December 05, 2017
https://issues.dlang.org/show_bug.cgi?id=3720

Steven Schveighoffer <schveiguy@yahoo.com> changed:

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

--- Comment #12 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Isn't this the type/pointer assigned to delegates?

e.g.:

S s;
auto dg = &s.fun;
assert(dg.funcptr == &S.fun);

So it could be useful if you are doing something funky with the function pointer portion of a delegate. Like for instance, selecting at runtime which function pointer to use.

My preference would be to embed in the type of the function pointer, the fact that it takes a hidden context pointer. Then the compiler can disallow simply calling it without stuffing it into a delegate.

--
December 05, 2017
https://issues.dlang.org/show_bug.cgi?id=3720

--- Comment #13 from Mike Franklin <slavo5150@yahoo.com> ---
> My preference would be to embed in the type of the function pointer, the fact that it takes a hidden context pointer. Then the compiler can disallow simply calling it without stuffing it into a delegate.

Is that different from (2) in comment 11?

--
December 05, 2017
https://issues.dlang.org/show_bug.cgi?id=3720

--- Comment #14 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Mike Franklin from comment #13)
> > My preference would be to embed in the type of the function pointer, the fact that it takes a hidden context pointer. Then the compiler can disallow simply calling it without stuffing it into a delegate.
> 
> Is that different from (2) in comment 11?

Yes, I would want to introduce a new piece of the type system, e.g.:

void function(this)

which means "I can only be called when in a delegate".

At the moment, we can't type the context pointer, since it's void *, and the types will have problems if you are playing fast and loose with the delegate internals (there is definitely code out there that plays with delegate function pointers).

Perhaps there is room here to have loose type requirements, but I don't know how that might break existing code. Worth exploring, though.

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

FeepingCreature <default_357-line@yahoo.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |default_357-line@yahoo.de

--- Comment #15 from FeepingCreature <default_357-line@yahoo.de> ---
Here's a subset of this that should be fixed immediately:

class S {
  void fun() { }
  static void function() fun2() { return &fun; }
}

There is *no* good reason to allow this, because you can always do &S.fun explicitly. This looks *way* too innocuous for the horror that it is.

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

MichaelZ <dlang.org@bregalad.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dlang.org@bregalad.de

--
March 04, 2018
https://issues.dlang.org/show_bug.cgi?id=3720

Walter Bright <bugzilla@digitalmars.com> changed:

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

--- Comment #16 from Walter Bright <bugzilla@digitalmars.com> ---
If `@safe` is added, the example fails to compile with:

test.d(9): Error: `this` reference necessary to take address of member `fun` in `@safe` function `main`

which is expected behavior.

--
March 04, 2018
https://issues.dlang.org/show_bug.cgi?id=3720

--- Comment #17 from FeepingCreature <default_357-line@yahoo.de> ---
Right, but I think it's more of a syntax issue. Taking the address of a member function without a this pointer may in rare cases be useful, but I don't see what purpose it serves that we're able to take the address without even using the class name, ie. &fun in static.

--
August 27, 2020
https://issues.dlang.org/show_bug.cgi?id=3720

ZombineDev <petar.p.kirov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |petar.p.kirov@gmail.com
         Resolution|INVALID                     |---

--- Comment #18 from ZombineDev <petar.p.kirov@gmail.com> ---
Reopening as this issue is a too ugly issue to be left unaddressed.

I suggest the following plan going forward:
1. Deprecate the expression &<AggregateType>.<memberFunction> even in @system
code, but allow the equivalent:
  &__traits(getMember, <AggregateType>, "<memberFunction>")

as we need to have migration path for the small amount of code that is able to correctly use &<AggregateType>.<memberFunction>

2. After deprecation period is finished, reintroduce the &<AggregateType>.<memberFunction> but with different semantics: retunring a delegate with context pointer set to null.

--
January 09, 2021
https://issues.dlang.org/show_bug.cgi?id=3720

Bolpat <qs.il.paperinik@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qs.il.paperinik@gmail.com

--