[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 RazvanN changed: What|Removed |Added Status|REOPENED|RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |DUPLICATE --- Comment #12 from RazvanN --- This actually is a dup of 3720. The underlying issue is how to treat the type of a delegate. Right now, the delegate type consists of a function pointer, which in turn has function type and a context pointer. Any fix to this organization is going to solve this issue also. *** This issue has been marked as a duplicate of issue 3720 *** --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 tyckesak changed: What|Removed |Added Blocks||22979 Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=22979 [Issue 22979] "Pointers-to-member" with attributes --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 Simen Kjaeraas changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #11 from Simen Kjaeraas --- *** Issue 20110 has been marked as a duplicate of this issue. *** --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 Mike Franklin changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=3720 --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 Vladimir Panteleev changed: What|Removed |Added Hardware|x86_64 |All OS|Linux |All --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 --- Comment #10 from Sprink --- (In reply to Dicebot from comment #9) > Because I disagree with your proposed fix and overall judgement of the > problem but don't want to argue about it in context of this issue. In what context then? After a fix for this is pushed out the door without even discussing alternative solutions to the problem because the test code in an issue was a tad bit different? These issues are directly related, pushing one fix out the door without even discussing alternatives is just nonsense. > It is more intrusive change (will fail in more context) and I think that > getting address of a method as a delegate is perfectly legitimate code - it > would allow to set `dg.ptr` manually later to call it with arbitrary context. Which wouldn't be allowed in @safe code and would be more error prone cause dg.ptr is of type void*. When a very specific type is needed for the delegate to work properly. Adding a member-to-function pointer type would allow for it to be used in @safe code, would be less error prone as you can work with the type system to ensure you pass the correct type, rather than void* for "dg.ptr". It'll also allow D to better interface with C++, related to issue 16527. What exactly don't you agree with here? With your fix issue 3720 is still a problem with a "dg.ptr" set to null, doesn't work in @safe code and you can convert any pointer type to void* for "dg.ptr". --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 --- Comment #9 from Dicebot --- (In reply to Sprink from comment #8) > Why bother fixing this issue by just changing the type to a delegate? You > are just making a temporary fix that has the potential to break code out > there. Then you are just going to have to cause the same breakage when the > actual underlying issue is fixed. This really shouldn't be half-assed. Because I disagree with your proposed fix and overall judgement of the problem but don't want to argue about it in context of this issue. Finding a way to put a deprecation stage into this stage is something I keep thinking about. > If you are going to do anything, make taking the address of a member > function without an object an error. That way it'll cause the same breakage > but then people won't continue to use it and won't cause a second breakage. It is more intrusive change (will fail in more context) and I think that getting address of a method as a delegate is perfectly legitimate code - it would allow to set `dg.ptr` manually later to call it with arbitrary context. --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 --- Comment #8 from Sprink --- Why bother fixing this issue by just changing the type to a delegate? You are just making a temporary fix that has the potential to break code out there. Then you are just going to have to cause the same breakage when the actual underlying issue is fixed. This really shouldn't be half-assed. If you are going to do anything, make taking the address of a member function without an object an error. That way it'll cause the same breakage but then people won't continue to use it and won't cause a second breakage. --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 --- Comment #7 from Dicebot --- (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. --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 --- Comment #6 from uplink.co...@googlemail.com --- I am going to take care of this. I might take a while though. --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 uplink.co...@googlemail.com changed: What|Removed |Added Assignee|nob...@puremagic.com|uplink.co...@googlemail.com --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 Dicebot changed: What|Removed |Added CC||pub...@dicebot.lv --- Comment #5 from Dicebot --- (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. --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 --- Comment #4 from Sprink --- (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 --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 Marenz changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #3 from Marenz --- 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. --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 Sprink changed: What|Removed |Added Status|NEW |RESOLVED CC||sprink.nore...@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from Sprink --- *** This issue has been marked as a duplicate of issue 3720 *** --
[Issue 17080] Can assign member-function-ptr to free-function-ptr
https://issues.dlang.org/show_bug.cgi?id=17080 uplink.co...@googlemail.com changed: What|Removed |Added Keywords||accepts-invalid CC||uplink.co...@googlemail.com Summary|Can assign delegate to |Can assign |function|member-function-ptr to ||free-function-ptr --