[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 --- Comment #53 from Steven Schveighoffer --- (In reply to RazvanN from comment #52) > However, in master, this is "fixed" but deprecated, so > the functionality still can be used. Not for LDC or GDC. --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #52 from RazvanN --- (In reply to Max Samukha from comment #51) > Is anybody working on this? Not that I know of. However, in master, this is "fixed" but deprecated, so the functionality still can be used. --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Max Samukha changed: What|Removed |Added CC||maxsamu...@gmail.com --- Comment #51 from Max Samukha --- Is anybody working on this? --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Thomas Brix Larsen changed: What|Removed |Added CC||b...@brix-verden.dk --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #50 from Simen Kjaeraas --- I'll happily re-post my bounty from last time[0]: $200 to whoever fixes this. [0]: https://forum.dlang.org/post/gjzrklkxfmgjjdfor...@forum.dlang.org --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 timon.g...@gmx.ch changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #49 from timon.g...@gmx.ch --- It seems this is no longer fixed. This raises some questions as there seem to have been bounties for this issue. --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 --- Comment #48 from Dlang Bot --- dlang/dmd pull request #9702 "Deprecate "Fix for the non-global template issue 5710"" was merged into master: - e12476303a698305b1904892d07e686051643549 by Iain Buclaw: Deprecate "Fix for the non-global template issue 5710" https://github.com/dlang/dmd/pull/9702 --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 --- Comment #47 from Dlang Bot --- dlang/phobos pull request #7441 "Change all bug ID to links" was merged into master: - 4c85510313cc84be8271e6668d622ae563bc55a7 by Geod24: Improve comment about issue 5710 https://github.com/dlang/phobos/pull/7441 --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 --- Comment #46 from Dennis --- *** Issue 3051 has been marked as a duplicate of this issue. *** --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #45 from Dlang Bot --- dlang/dmd pull request #9282 "Fix for the non-global template issue 5710" was merged into master: - 182eb1bc09e40b5fb1298367f685cb9d66685c0e by سليمان السهمي (Suleyman Sahmi): Fix issue 5710 - Remove non-global template restriction https://github.com/dlang/dmd/pull/9282 --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #44 from Dlang Bot --- @SSoulaimane updated dlang/dmd pull request #9282 "[WIP] Fix for the non-global template issue" fixing this issue: - Fix issue 5710 - Remove non-global template restriction https://github.com/dlang/dmd/pull/9282 --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Seb changed: What|Removed |Added CC||greeen...@gmail.com --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Simen Kjaeraas changed: What|Removed |Added CC||simend...@gmail.com --- Comment #43 from Simen Kjaeraas --- *** Issue 11098 has been marked as a duplicate of this issue. *** --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 calex changed: What|Removed |Added CC||calex+bugzilla-mail@aristow ||eb.net --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 --- Comment #42 from Martin Nowak --- I'm hearing that C++ closures simply pass one pointer/reference for each referenced variable, which does support an arbitrary amount of contexts. Sounds interesting. --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Martin Nowak changed: What|Removed |Added OS|Windows |All --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Maksim Zholudev changed: What|Removed |Added CC||maxim...@gmail.com --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #41 from Vladimir Panteleev --- Added $50 to existing $100 bounty: https://www.bountysource.com/issues/1375082-cannot-use-delegates-as-parameters-to-non-global-template --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 --- Comment #40 from Sobirari Muhomori --- This is exactly my point: don't make it a different thing. The function needs two contexts, they can be nested, backend and frontend can construct and access such nested contexts, no need to reimplement it in a different way. --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710
--- Comment #39 from timon.g...@gmx.ch ---
(In reply to Sobirari Muhomori from comment #38)
> (In reply to Martin Nowak from comment #34)
> > It's still challenging to implement all the IR gen for this.
>
> BTW, looks like all the code generation was there for ages:
>
> struct A
> {
> int a;
> int delegate() foo()
> {
> int b;
> int bar()
> {
> return a+b;
> }
> int delegate() d=&bar;
> b=1;
> return d;
> }
> }
>
> Here nested function `bar` accesses both stack variable `b` and member field
> `a` through single context pointer in delegate `d` as if it has two contexts
> - closure pointer and `this` pointer.
This is not the same thing. Here, one context is nested in the other.
--
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710
--- Comment #38 from Sobirari Muhomori ---
(In reply to Martin Nowak from comment #34)
> It's still challenging to implement all the IR gen for this.
BTW, looks like all the code generation was there for ages:
struct A
{
int a;
int delegate() foo()
{
int b;
int bar()
{
return a+b;
}
int delegate() d=&bar;
b=1;
return d;
}
}
Here nested function `bar` accesses both stack variable `b` and member field
`a` through single context pointer in delegate `d` as if it has two contexts -
closure pointer and `this` pointer.
--
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 --- Comment #37 from Sobirari Muhomori --- (In reply to Martin Nowak from comment #34) > Yes, this is similar to comment 31 and it should work using the normal > delegate pointer. It's still challenging to implement all the IR gen for > this. My proposal is to have single context instead of multicontext - should have less difficulty for the caller - no need to generate the array, only a normal closure context. --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 --- Comment #36 from deadalnix --- Just putting that here: http://wiki.dlang.org/DIP30 --
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710
--- Comment #35 from Martin Nowak ---
(In reply to Kenji Hara from comment #29)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > (In reply to comment #25)
> > > > Good to see, that you already know this solution.
> > > > I think the biggest hurdle to implement is teaching the IR/backend to
> > > > get
> > > > doStuff's this pointer from an array.
> > >
> > > Unfortunately it is merely an idea, and it would break existing delegate
> > > ABI.
> >
> > How would it break the existing delegate ABI?
>
> Sorry, it was not good words. It will break some existing assumptions around
> delegate. For example:
>
> class C {
> void foo() {}
> void bar(alias fun)() {}
> }
> void test()
> {
> C c = new C();
> auto dg1 = &c.foo;
>
> /* currently upsupported case.
>
> void nested() {}
> auto dg2 = &c.bar!nested;
> dg2();
>
>#1. dg2.ptr cannot become c.
>Instead, it should point to the "context pointer list".
>But, if dg2 is returned from the function 'test', the list
>should be allocated on heap.
> */
> }
>
> #1 is necessary for the multiple-context delegates. But applying same rule
> for existing one-context delegates will add hidden runtime cost against
> existing code.
>
> To avoid the cost, we should introduce the second delegate type for the
> multiple-context delegates. Then, the typeof(dg1) and typeof(dg2) will
> become incompatible. It will make D's type system more complicated.
>
> Therefore, I had withdrawn my idea. It won't add enough benefits compared
> with the necessary complexity.
The type will be 'delegate void()' for both cases. True, 'dg1.ptr is c' and
'dg2.ptr !is c', but that doesn't affect the type as we don't inherit C++'s
member pointer complexity. The function 'void bar(alias fun)()' can access the
this pointer through 'dg2.ptr'.
--
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710
--- Comment #34 from Martin Nowak ---
(In reply to Sobirari Muhomori from comment #33)
> A slightly more straightforward solution: the passed context is effectively
> a closure, and it can contain any variables, so let's just pass this pointer
> in the closure context struct. All the rules of closures apply.
>
> struct main_add_closure_context
> {
> auto var1;
> auto var2;
> Foo foo_this;
> auto var3;
> auto var4;
> }
>
> This context is like any normal closure, the `add` can simply use it. Also
> pass it instead of `this` argument to doStuff(alias fun), which in its turn
> should be taught to get `this` reference from the passed context struct.
Yes, this is similar to comment 31 and it should work using the normal delegate
pointer. It's still challenging to implement all the IR gen for this.
--
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710
--- Comment #33 from Sobirari Muhomori ---
A slightly more straightforward solution: the passed context is effectively a
closure, and it can contain any variables, so let's just pass this pointer in
the closure context struct. All the rules of closures apply.
struct main_add_closure_context
{
auto var1;
auto var2;
Foo foo_this;
auto var3;
auto var4;
}
This context is like any normal closure, the `add` can simply use it. Also pass
it instead of `this` argument to doStuff(alias fun), which in its turn should
be taught to get `this` reference from the passed context struct.
--
[Issue 5710] cannot use delegates as parameters to non-global template
https://issues.dlang.org/show_bug.cgi?id=5710 --- Comment #32 from timon.g...@gmx.ch --- (In reply to Kenji Hara from comment #29) > ... > > #1 is necessary for the multiple-context delegates. But applying same rule > for existing one-context delegates There is no particular reason to apply the same rule for existing one-context delegates. Those work already. > will add hidden runtime cost against existing code. > ... Hence it seems like a bad idea to apply the same rule for existing one-context delegates. > To avoid the cost, ... There is no need to introduce it in the first place. --
[Issue 5710] cannot use delegates as parameters to non-global template
https://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #31 from Martin Nowak 2013-11-18 13:58:12 PST --- (In reply to comment #29) > #1 is necessary for the multiple-context delegates. But applying same rule for > existing one-context delegates will add hidden runtime cost against existing > code. For single context it's dg.ptr = cast(void*)c; For multi-context pointer it's void*[2] __ctxt = [cast(void*)c, funcThis]; dg.ptr = cast(void*)&__ctxt; And yes, if the delegate escapes the scope the __ctxt becomes a closure variable and is heap allocated (dg.ptr will point into the heap). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
https://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #30 from David Nadlinger 2013-11-18 03:42:49 PST --- (In reply to comment #29) > #1 is necessary for the multiple-context delegates. But applying same rule for > existing one-context delegates will add hidden runtime cost against existing > code. I don't quite see why the behavior for existing delegates should change. The interpretation of the context argument is up to the callee. The only requirement is that the caller knows how to construct it, for the rest of the world it's just an opaque pointer. So, I don't see a reason why the new scheme can't decay to the old one as an optimization, if possible. I haven't looked at DMD's implementation in any detail, but at least for LDC, the required adaptions would be rather straightforward. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
https://d.puremagic.com/issues/show_bug.cgi?id=5710
--- Comment #29 from Kenji Hara 2013-11-18 02:00:56 PST
---
(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > Good to see, that you already know this solution.
> > > I think the biggest hurdle to implement is teaching the IR/backend to get
> > > doStuff's this pointer from an array.
> >
> > Unfortunately it is merely an idea, and it would break existing delegate
> > ABI.
>
> How would it break the existing delegate ABI?
Sorry, it was not good words. It will break some existing assumptions around
delegate. For example:
class C {
void foo() {}
void bar(alias fun)() {}
}
void test()
{
C c = new C();
auto dg1 = &c.foo;
/* currently upsupported case.
void nested() {}
auto dg2 = &c.bar!nested;
dg2();
#1. dg2.ptr cannot become c.
Instead, it should point to the "context pointer list".
But, if dg2 is returned from the function 'test', the list
should be allocated on heap.
*/
}
#1 is necessary for the multiple-context delegates. But applying same rule for
existing one-context delegates will add hidden runtime cost against existing
code.
To avoid the cost, we should introduce the second delegate type for the
multiple-context delegates. Then, the typeof(dg1) and typeof(dg2) will become
incompatible. It will make D's type system more complicated.
Therefore, I had withdrawn my idea. It won't add enough benefits compared with
the necessary complexity.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
https://d.puremagic.com/issues/show_bug.cgi?id=5710 Jacob Carlborg changed: What|Removed |Added CC||d...@me.com --- Comment #28 from Jacob Carlborg 2013-11-18 01:49:55 PST --- (In reply to comment #26) > Unfortunately it is merely an idea, and it would break existing delegate ABI. Can't the array solution only be used when needed. Since any place where it's needed currently won't compile, it won't break anything? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
https://d.puremagic.com/issues/show_bug.cgi?id=5710 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #27 from timon.g...@gmx.ch 2013-11-18 01:09:27 PST --- (In reply to comment #26) > (In reply to comment #25) > > Good to see, that you already know this solution. > > I think the biggest hurdle to implement is teaching the IR/backend to get > > doStuff's this pointer from an array. > > Unfortunately it is merely an idea, and it would break existing delegate ABI. How would it break the existing delegate ABI? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
https://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #26 from Kenji Hara 2013-11-17 17:51:54 PST --- (In reply to comment #25) > Good to see, that you already know this solution. > I think the biggest hurdle to implement is teaching the IR/backend to get > doStuff's this pointer from an array. Unfortunately it is merely an idea, and it would break existing delegate ABI. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
https://d.puremagic.com/issues/show_bug.cgi?id=5710
Martin Nowak changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #25 from Martin Nowak 2013-11-17 08:51:48 PST ---
(In reply to comment #9)
> My idea:
> doStuff receives a context pointer that points 'an array of context pointers'.
> Backend receives code like follows...
>
> uint doStuff(alias fun)(uint a, uint b, void** this) // not void* this
> {
> // (*this + 0) points the object Foo
> // (*this + 1) points the stack frame of main()
>
> //return fun(a, b);
> return fun(a, b, (*this + 1));
> }
>
> Caller of doStuff have to create array of context pointers.
>
> void main(){
> ...
> //foo.doStuff!add(1, 2);
> void*[2] thisarray = [(stack frame of main), foo];
> doStuff(a, b, thisarray.ptr);
> }
Good to see, that you already know this solution.
I think the biggest hurdle to implement is teaching the IR/backend to get
doStuff's this pointer from an array.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710
--- Comment #24 from Steven Schveighoffer 2013-05-07
05:52:41 PDT ---
(In reply to comment #23)
>
> No, because you can call the same template instantiation with different "this"
> pointers even though the "alias" parameter is the same. Each "this" pointer
> will be at a different location in the stack frame, so "foo" can't possibly
> know which one to use.
Yes, you are right, thanks for explaining.
> With Kenji's idea, you have 2 pointers on the stack:
>
> struct multi_context {
> stack_frame* base_ptr; // pointer to start of stack frame
> T* this_ptr; // pointer
> }
>
> struct stack_frame {
> // other stuff
> multi_context context;
> }
>
> "foo" is called by passing in a pointer to the "multi_context" struct from
> which both the "this_ptr" and "base_ptr" can be obtained.
Likely the this_ptr is repeated inside the stack frame for normal access during
the function.
Anyway, the point is moot since only Kenji's solution is valid.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710
--- Comment #23 from Diggory 2013-05-06 18:58:25 PDT
---
(In reply to comment #22)
> (In reply to comment #21)
>
> > The problem with Rainer's idea is that the callee would need to know the
> > layout
> > of the stack frame in the context in which the delegate was bound, which in
> > general it cannot know.
>
> The generated function MUST know the context of main, or else it can't call
> add. Remember, add is passed as an alias, not a delegate. Even if add is
> passed as a delegate, it's calling the delegate from main's stack-frame (i.e.
> two identical calls separated by a re-assignment of the delegate would call
> two
> different functions).
>
> Bear in mind that each call to doStuff with a different alias is a *different*
> instantiation, even for calls with the same inner function types because of
> the
> alias parameter. It is OK for each instantiation to be aware of the stack
> offset for 'this'.
No, because you can call the same template instantiation with different "this"
pointers even though the "alias" parameter is the same. Each "this" pointer
will be at a different location in the stack frame, so "foo" can't possibly
know which one to use.
> And it's 2 extra words, not 1. You need to store the 'array of context
> pointers' on the stack, which you do not need if you know the layout of the
> stack frame. If you think about it, it is actually very little different from
> Kenji's idea:
>
> uint doStuff(uint a, uint b, void** this) // not void* this
> {
> // (*this + 0) points the object Foo
> // (*this + 1) points the stack frame of main()
>
> Rainer's:
>
> uint doStuff(uint a, uint b, void* this)
> {
> // this points the stack frame of main()
> // *(this + N) points the object Foo
>
> Note the difference is that N is a compile time constant, like Kenji's 1.
With Kenji's idea, you have 2 pointers on the stack:
struct multi_context {
stack_frame* base_ptr; // pointer to start of stack frame
T* this_ptr; // pointer
}
struct stack_frame {
// other stuff
multi_context context;
}
"foo" is called by passing in a pointer to the "multi_context" struct from
which both the "this_ptr" and "base_ptr" can be obtained.
With Rainer's idea, you have 1 pointer on the stack:
struct stack_frame {
// other stuff
T* this_ptr;
}
That is only a difference of one :P Rainer's idea needs a "this_ptr" on the
stack otherwise there is no way for "foo" to access it, whereas Kenji's version
doesn't.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710
--- Comment #22 from Steven Schveighoffer 2013-05-06
18:10:18 PDT ---
(In reply to comment #21)
> The problem with Rainer's idea is that the callee would need to know the
> layout
> of the stack frame in the context in which the delegate was bound, which in
> general it cannot know.
The generated function MUST know the context of main, or else it can't call
add. Remember, add is passed as an alias, not a delegate. Even if add is
passed as a delegate, it's calling the delegate from main's stack-frame (i.e.
two identical calls separated by a re-assignment of the delegate would call two
different functions).
Bear in mind that each call to doStuff with a different alias is a *different*
instantiation, even for calls with the same inner function types because of the
alias parameter. It is OK for each instantiation to be aware of the stack
offset for 'this'.
And it's 2 extra words, not 1. You need to store the 'array of context
pointers' on the stack, which you do not need if you know the layout of the
stack frame. If you think about it, it is actually very little different from
Kenji's idea:
uint doStuff(uint a, uint b, void** this) // not void* this
{
// (*this + 0) points the object Foo
// (*this + 1) points the stack frame of main()
Rainer's:
uint doStuff(uint a, uint b, void* this)
{
// this points the stack frame of main()
// *(this + N) points the object Foo
Note the difference is that N is a compile time constant, like Kenji's 1.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #21 from Diggory 2013-05-06 17:50:32 PDT --- (In reply to comment #20) > (In reply to comment #19) > > > How the parameters are actually passed is fairly irrelevant, the main > > problem > > which needs to be solved is how to store two context pointers in a delegate, > > If you look closely at the original example, no delegates are used. add is > passed by alias, not by delegate. But I see the point, if you took > &foo.doStuff!add, you would be screwed. > > What about Rainer's idea? This would require less memory consumption from the > stack. > The problem with Rainer's idea is that the callee would need to know the layout of the stack frame in the context in which the delegate was bound, which in general it cannot know. If you refine it so that you arrange for part of the stack frame to follow a predefined layout so that the callee knows where to find the "this" pointer, you then need a second pointer to point to the beginning of the stack frame (because it may not be possible to place this structure at the start of the stack frame) and you end up with something that is identical to Kenji's solution. It only uses one extra pointer over what would be required if you had a dedicated 2 context pointer delegate type, so I don't think that memory consumption is much of a problem. > Anyone consider that this is no longer the case (in any valid solution so > far)? > > auto dg = &foo.doStuff!add; > assert(foo !is dg.ptr); > > Don't know if that's an unbreakable rule though... That assertion is only currently valid for member function delegates. Nested functions store the frame pointer in "dg.ptr". I would say that "foo" in this case is no longer strictly a member function, but is some weird mix between a member function and an anonymous nested function, so it's perfectly reasonable to expect it to behave differently in that case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #20 from Steven Schveighoffer 2013-05-06 16:59:08 PDT --- (In reply to comment #19) > How the parameters are actually passed is fairly irrelevant, the main problem > which needs to be solved is how to store two context pointers in a delegate, If you look closely at the original example, no delegates are used. add is passed by alias, not by delegate. But I see the point, if you took &foo.doStuff!add, you would be screwed. What about Rainer's idea? This would require less memory consumption from the stack. Anyone consider that this is no longer the case (in any valid solution so far)? auto dg = &foo.doStuff!add; assert(foo !is dg.ptr); Don't know if that's an unbreakable rule though... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710
--- Comment #19 from Diggory 2013-05-06 15:20:20 PDT
---
(In reply to comment #18)
> (In reply to comment #17)
> > Kenji's solution means two context pointer delegates are just normal
> > delegates
> > (still a function pointer and a context pointer) so they can still be passed
> > around as usual.
>
> OK, but how does it devolve to a 'this' pointer for the class? In other
> words,
> doesn't the compiler have to treat 'this' in a special way while inside
> doStuff?
>
> Is that OK? I guess it's not too important, but it would be a new ABI call
> type, no?
>
> I wonder if it wouldn't be better to push 'foo' and then the stack frame on to
> the stack, and then the call to doStuff would look like:
>
> uint doStuff(uint a, uint b, void* this)
> {
> // *(&(this) + 0) points the object Foo
> // *(&(this) + 1) points the stack frame of main()
>
> //return fun(a, b);
> return fun(a, b, *(&this + 1));
> }
>
> Would that not work? I'd actually rather just see another parameter:
>
> uint doStuff(uint a, uint b, void *this1, void *this)
> {
>return fun(a, b, this1);
> }
>
> That is simpler for me to understand, I don't see why the compiler can't do
> this.
How the parameters are actually passed is fairly irrelevant, the main problem
which needs to be solved is how to store two context pointers in a delegate,
when currently delegates look like this:
struct dg {
void* contextPtr;
void* funcPtr;
}
If you add an extra context pointer, you have to either make all delegates
bigger:
struct dg {
void* contextPtr1;
void* contextPtr2;
void* funcPtr;
}
Or have two or more types of delegates which cannot be used interchangeably (in
which case they're fairly useless as delegates!)
Kenji is suggesting something like this:
struct dg {
void* contextPtr;
void* funcPtr;
}
struct multiContext {
void* contextPtr1;
void* contextPtr2;
}
The "multiContext" struct is completely invisible to anyone using the delegate,
and it doesn't affect in the slightest how the delegate is called, you're still
passing in one context pointer.
The decoding into two context pointers is handled by the callee, because the
callee knows how many context pointers it should have. (Think about it, how can
a function not know how many context pointers it needs!)
It should be possible to call a delegate without having to know anything about
the receiver other than what arguments it takes.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710
--- Comment #18 from Steven Schveighoffer 2013-05-06
14:50:59 PDT ---
(In reply to comment #17)
> Kenji's solution means two context pointer delegates are just normal delegates
> (still a function pointer and a context pointer) so they can still be passed
> around as usual.
OK, but how does it devolve to a 'this' pointer for the class? In other words,
doesn't the compiler have to treat 'this' in a special way while inside
doStuff?
Is that OK? I guess it's not too important, but it would be a new ABI call
type, no?
I wonder if it wouldn't be better to push 'foo' and then the stack frame on to
the stack, and then the call to doStuff would look like:
uint doStuff(uint a, uint b, void* this)
{
// *(&(this) + 0) points the object Foo
// *(&(this) + 1) points the stack frame of main()
//return fun(a, b);
return fun(a, b, *(&this + 1));
}
Would that not work? I'd actually rather just see another parameter:
uint doStuff(uint a, uint b, void *this1, void *this)
{
return fun(a, b, this1);
}
That is simpler for me to understand, I don't see why the compiler can't do
this.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 Diggory changed: What|Removed |Added CC||digg...@googlemail.com --- Comment #17 from Diggory 2013-05-06 11:46:02 PDT --- Kenji's solution means two context pointer delegates are just normal delegates (still a function pointer and a context pointer) so they can still be passed around as usual. There's no need for dynamic allocation because if the stack frame referred to by a delegate is invalid when the delegate is called, the results are already undefined. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #16 from Steven Schveighoffer 2013-05-06
11:01:01 PDT ---
(In reply to comment #0)
> class Foo {
> uint doStuff(alias fun)(uint a, uint b) { return fun(a, b); }
> }
>
> void main() {
> auto foo = new Foo;
>
> uint add(uint a, uint b) { return a + b; }
>
> foo.doStuff!add(1, 2);
> }
This is definitely not good.
I don't think we need to alter the ABI for this. The 'this' pointer of the
frame isn't used inside doStuff, just inside the template instantiation. The
compiler can be smart enough to recognize that fun(a, b) is really:
fun(a, b, frameptr), and that frameptr is passed implicitly as a parameter. It
does not have to be spelled out in the parameters to doStuff.
I don't like the *spirit* of kenji's solution, that context pointers are an
array. Given that this is a template, and the compiler has the ability to pass
and receive, and write code for, any hidden parameter it wishes, it's simply a
matter of lowering. Like foreach, which injects hidden code and function
return handling.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 deadalnix changed: What|Removed |Added CC||deadal...@gmail.com --- Comment #15 from deadalnix 2013-01-21 18:16:38 PST --- (In reply to comment #1) > The reason this does not work is because the instantiation of the doStuff() > function would require *two* context pointers: > > 1. a 'this' pointer to the object Foo > 2. a 'this' pointer to the stack frame of main() > > and there can be only one. > > It will work if you declare add() as being static, because then you're saying > that it does not need a context pointer to main(). Why there could only be one ? I see no real problem about having 2 of them. Note that I have plenty of workaround on top of several forms of that issue. Passing the delegate as argument instead of alias is going to make things much slower. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 klickverbot changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #14 from klickverbot 2012-07-30 11:14:54 PDT --- (In reply to comment #12) > If not, I think I can use UFCS to move > std.parallelism.map, reduce, etc. out of TaskPool w/o changing the call > syntax, > and work around this bug. I don't think you can, because D doesn't have ADL, so if somebody just has the TaskPool type, but not the module in scope, the free functions would not be found. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #13 from Andrei Alexandrescu 2012-07-30 09:38:34 PDT --- I think Kenji's design is very promising. I assume it uses static arrays, i.e. no dynamic allocation. On the other hand, we need to think this through quite carefully. One example is that some frames must be dynamically allocated, and others don't. So the array of frame pointers would contain in the general case a mix of pointers to the stack and pointers to the heap. Hopefully that doesn't impact the design. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #12 from David Simcha 2011-12-28 06:33:47 PST --- Any chance of this getting fixed anytime soon now that we're addressing a whole bunch of lambda-related issues? If not, I think I can use UFCS to move std.parallelism.map, reduce, etc. out of TaskPool w/o changing the call syntax, and work around this bug. This is kind of ugly, though, so I'd rather not do so if this bug is going to get fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #11 from David Simcha 2011-08-23 21:48:56 PDT --- (In reply to comment #6) > 1. function pointer > 2. function pointer with context pointer (delegate) > 3. function pointer with two context pointers > > Is that really where we want to go? If it's really that much of a problem, how about we just forbid taking the address of functions with two context pointers? It would be a heck of a lot less of an annoying limitation than this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710
--- Comment #10 from David Simcha 2011-08-19 07:03:02 PDT
---
(In reply to comment #9)
> My idea:
> doStuff receives a context pointer that points 'an array of context pointers'.
> Backend receives code like follows...
>
> uint doStuff(uint a, uint b, void** this) // not void* this
> {
> // (*this + 0) points the object Foo
> // (*this + 1) points the stack frame of main()
>
> //return fun(a, b);
> return fun(a, b, (*this + 1));
> }
>
> Caller of doStuff have to create array of context pointers.
>
> void main(){
> ...
> //foo.doStuff!add(1, 2);
> void*[2] thisarray = [(stack frame of main), foo];
> doStuff(a, b, thisarray.ptr);
> }
Sounds great if you can pull it off. I was thinking the same thing, but I'm
not familiar enough with the DMD codebase to know how easy/hard it would be to
implement. This would remove some really silly/annoying limitations from
std.parallelism.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710
Kenji Hara changed:
What|Removed |Added
CC||k.hara...@gmail.com
--- Comment #9 from Kenji Hara 2011-06-10 06:44:19 PDT ---
My idea:
doStuff receives a context pointer that points 'an array of context pointers'.
Backend receives code like follows...
uint doStuff(uint a, uint b, void** this) // not void* this
{
// (*this + 0) points the object Foo
// (*this + 1) points the stack frame of main()
//return fun(a, b);
return fun(a, b, (*this + 1));
}
Caller of doStuff have to create array of context pointers.
void main(){
...
//foo.doStuff!add(1, 2);
void*[2] thisarray = [(stack frame of main), foo];
doStuff(a, b, thisarray.ptr);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 Brad Roberts changed: What|Removed |Added CC||bra...@puremagic.com --- Comment #8 from Brad Roberts 2011-03-07 01:19:35 PST --- (In reply to comment #6) > Consider if we add another type - a function pointer with two context > pointers. > Now we have quite a menagerie: > > 1. function pointer > 2. function pointer with context pointer (delegate) > 3. function pointer with two context pointers > > Is that really where we want to go? Yes. They're just function parameters. Define how they're passed and pass 'em. It doesn't need to be fancy or tricky. It's not particularly different from passing dynamic arrays having a well defined parameter layout. Just considered it just a tuple of two pointers. It's not rocket science. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #7 from Rainer Schuetze 2011-03-07 00:35:26 PST --- This could be implemented with a single context pointer, if the this pointer of the Foo instance can be found through the stack frame pointer. In the example the pointer to foo is already there, but in the more general case, a hidden stack/closure variable needs to be used. I'm not sure how much it would complicate code generation, though. It could end up as a can of worms, e.g. having to deal with multiple aliases to different kind of context pointers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #6 from Walter Bright 2011-03-06 22:18:04 PST --- (In reply to comment #4) > First, the compiler should figure out that add does not need a frame pointer > and consider it a static inner function, not a delegate. Delegates and functions are different types. Deciding, based on the contents of a function body, whether it is a function or a delegate makes for non-obvious changes in type. Secondly, people are going to access outer variables from a nested function, and will not expect it to break their code. > Second, we need to agree that the reason you invoke is tied to the > implementation - you use the same pointer for the class and for the hidden > frame pointer, whereas of course there's no imposition to do so. Making them use the same ABI means that they have the same type and are interchangeable. This is a big deal. I don't think this will survive "a class member function pointer is a different type than a nested function pointer". > The hidden "this" parameter could go pretty much anywhere else. > One way or another we must fix this. Oddly, a number of similar uses do work > "by mistake", so at this moment we don't have a clear grasp on what > distinguishes cases that work from cases that don't. > We need to pursue this like a bloodhound and aggressively make as many cases > as > possible work transparently. This is a major asset of D over virtually all > other languages. Consider if we add another type - a function pointer with two context pointers. Now we have quite a menagerie: 1. function pointer 2. function pointer with context pointer (delegate) 3. function pointer with two context pointers Is that really where we want to go? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #5 from David Simcha 2011-03-06 16:29:07 PST --- (In reply to comment #3) > (In reply to comment #2) > > So is this an WONTFIX, then? > > Unless there's an epiphany somewhere, yes. How would you suggest two hidden > context pointers be handled? Is it clear that two context pointers are > required > (at least for this example)? Honestly, I don't know enough about the details of how DMD works under the hood to come up with a good answer, but my completely naive answer would be to pass the delegate context pointer in as a hidden argument between the explicit arguments and the hidden class instance pointer. The class instance pointer is still passed last (no special casing) and the delegate context pointer lives on the stack somewhere as a regular stack variable and gets passed in when needed. > > > Unfortunately it severely hurts my > > std.parallelism design in some use cases, and a workaround for it would be a > > significant PITA to implement, make the API uglier, and possibly be > > inefficient. > > I don't know enough about your design to offer help with that. Perhaps instead > of an alias parameter, make fun explicitly a delegate? This would be the workaround, but I probably won't implement it because: 1. If I still keep alias parameters, I'll have to have two implementations of map(), reduce() and friends. This is ugly from both an API and an implementation perspective. 2. Delegates can't be inlined. Aliases can. 3. Delegates can only be instantiations of templates. Aliases can be templates. This means that a nested template function would have to be explicitly instantiated. This is ugly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 Andrei Alexandrescu changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #4 from Andrei Alexandrescu 2011-03-06 15:31:45 PST --- (In reply to comment #3) > (In reply to comment #2) > > So is this an WONTFIX, then? > > Unless there's an epiphany somewhere, yes. How would you suggest two hidden > context pointers be handled? Is it clear that two context pointers are > required > (at least for this example)? > > > Unfortunately it severely hurts my > > std.parallelism design in some use cases, and a workaround for it would be a > > significant PITA to implement, make the API uglier, and possibly be > > inefficient. > > I don't know enough about your design to offer help with that. Perhaps instead > of an alias parameter, make fun explicitly a delegate? There are several things here. First, the compiler should figure out that add does not need a frame pointer and consider it a static inner function, not a delegate. Second, we need to agree that the reason you invoke is tied to the implementation - you use the same pointer for the class and for the hidden frame pointer, whereas of course there's no imposition to do so. The hidden "this" parameter could go pretty much anywhere else. One way or another we must fix this. Oddly, a number of similar uses do work "by mistake", so at this moment we don't have a clear grasp on what distinguishes cases that work from cases that don't. We need to pursue this like a bloodhound and aggressively make as many cases as possible work transparently. This is a major asset of D over virtually all other languages. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #3 from Walter Bright 2011-03-06 15:19:12 PST --- (In reply to comment #2) > So is this an WONTFIX, then? Unless there's an epiphany somewhere, yes. How would you suggest two hidden context pointers be handled? Is it clear that two context pointers are required (at least for this example)? > Unfortunately it severely hurts my > std.parallelism design in some use cases, and a workaround for it would be a > significant PITA to implement, make the API uglier, and possibly be > inefficient. I don't know enough about your design to offer help with that. Perhaps instead of an alias parameter, make fun explicitly a delegate? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 --- Comment #2 from David Simcha 2011-03-06 11:05:37 PST --- So is this an WONTFIX, then? Unfortunately it severely hurts my std.parallelism design in some use cases, and a workaround for it would be a significant PITA to implement, make the API uglier, and possibly be inefficient. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5710] cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright 2011-03-06 10:16:43 PST --- The reason this does not work is because the instantiation of the doStuff() function would require *two* context pointers: 1. a 'this' pointer to the object Foo 2. a 'this' pointer to the stack frame of main() and there can be only one. It will work if you declare add() as being static, because then you're saying that it does not need a context pointer to main(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
