[Issue 17080] Can assign delegate to function

Jan 09, 2017

Jan 10, 2017

https://issues.dlang.org/show_bug.cgi?id=17080 --- Comment #1 from Marenz <dlang@supradigital.org> --- Note that this not only compiles but also does something very nasty if you call the resulting func. So this silently corrupts your memory which I consider quite dangerous. --

https://issues.dlang.org/show_bug.cgi?id=17080 Ketmar Dark <ketmar@ketmar.no-ip.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ketmar@ketmar.no-ip.org --

https://issues.dlang.org/show_bug.cgi?id=17080 Sprink <sprink.noreply@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sprink.noreply@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from Sprink <sprink.noreply@gmail.com> --- *** This issue has been marked as a duplicate of issue 3720 *** --

https://issues.dlang.org/show_bug.cgi?id=17080 Marenz <dlang@supradigital.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE |--- --- Comment #3 from Marenz <dlang@supradigital.org> --- I have been encouraged by Uplink|DMD to reopen this issue as it differs in a few aspects to the one it is marked a duplicate of: The issue 3720 should still compile because there isn't anything wrong with taking the address of a delegate, even without the instance (it would simply have .this (or whatever the name is) set to null. My example however shows an implicit conversion from function -> delegate and that should in no case compile. --

January 11, 2017

[Issue 17080] Can assign member-function-ptr to free-function-ptr

Posted by Sprink

Permalink

Sprink

Permalink

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

--- Comment #4 from Sprink <sprink.noreply@gmail.com> ---
(In reply to Marenz from comment #3)
> I have been encouraged by Uplink|DMD to reopen this issue as it differs in a few aspects to the one it is marked a duplicate of:
> 
> The issue 3720 should still compile because there isn't anything wrong with taking the address of a delegate, even without the instance (it would simply have .this (or whatever the name is) set to null.
> 
> My example however shows an implicit conversion from function -> delegate and that should in no case compile.

It is the same issue. If issue 3720 is fixed, then this issue wouldn't exist.

    auto fp = &S.fun;
    fp();

This is not valid code and only works because "auto" evaluates to a function. The use case for taking a pointer of a member function is to use it with objects, thus a delegate isn't suited here either.


    auto fp = &S.fun; // this line would need to stay the same

Now it's a matter how to call it? C++ uses a different syntax.

    S s;
    (s.*fp)();

In either case it is the exact same problem, that taking the address of a member function without an instance of that object results in the type being a regular function pointer.

It's not an implicit conversion from function -> delegate, the compiler incorrectly defines it as a function.

    writeln(typeof(fp).stringof); // prints void function(), not delegate

A bunch of other issues that illustrate the same thing are also marked
duplicates.
https://issues.dlang.org/show_bug.cgi?id=12154
https://issues.dlang.org/show_bug.cgi?id=12773

--

https://issues.dlang.org/show_bug.cgi?id=17080 Dicebot <public@dicebot.lv> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |public@dicebot.lv --- Comment #5 from Dicebot <public@dicebot.lv> --- (In reply to Sprink from comment #4) > It is the same issue. If issue 3720 is fixed, then this issue wouldn't exist. It is related to 3720 but, contrary to 3720, it can be fixed by simply typing `&S.fun` as a delegate (with null context ptr). Fixing 3720 as a whole is much more delicate matter which I'd prefer to not touch at this context. --

https://issues.dlang.org/show_bug.cgi?id=17080 uplink.coder@googlemail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|nobody@puremagic.com |uplink.coder@googlemail.com --

https://issues.dlang.org/show_bug.cgi?id=17080 --- Comment #7 from Dicebot <public@dicebot.lv> --- (In reply to uplink.coder from comment #6) > I am going to take care of this. > I might take a while though. FYI, this is quick hack I figured out after initial investigation that turns `addrOf` result into delegate: diff --git a/src/expression.d b/src/expression.d index 041ca86ef..0746d51df 100644 --- a/src/expression.d +++ b/src/expression.d @@ -10737,6 +10737,11 @@ extern (C++) final class AddrExp : UnaExp error("'this' reference necessary to take address of member %s in @safe function %s", f.toChars(), sc.func.toChars()); } } + + Expression ethis = new NullExp(loc, f.toAliasFunc().vthis.type); + Expression e = new DelegateExp(loc, ethis, f, ve.hasOverloads); + e = e.semantic(sc); + return e; } } } Haven't checked how it affects other code gen though. --

Forums