[D2] How to not full closure?

On Nov 27 2007 in this NG, there was this thread "How to not full closure?" See: http://www.digitalmars.com/d/archives/digitalmars/D/Howto_not_Full_closure_62508.html#N62542 For me, this is still a problem i see in using D2. E.g. when i pass a delegate as a search criteria to a containers find function, the triggered heap allocation can destroy all of the performance. Even worse, i cannot manually delete the stack frame. Imagine this function is called in a loop! So this still is a D2 show stopper for me. Delegates are a very important D feature. Full closures remove delegates for performance critical code, without giving an alternative. Please give this a high priority.

在 Mon, 14 Jul 2008 01:15:26 +0800，Frank Benoit <keinfarbton@googlemail.com> 写道: > On Nov 27 2007 in this NG, there was this thread "How to not full closure?" > See: http://www.digitalmars.com/d/archives/digitalmars/D/Howto_not_Full_closure_62508.html#N62542 > > For me, this is still a problem i see in using D2. > E.g. when i pass a delegate as a search criteria to a containers find function, the triggered heap allocation can destroy all of the performance. Even worse, i cannot manually delete the stack frame. > Imagine this function is called in a loop! > > So this still is a D2 show stopper for me. Delegates are a very important D feature. Full closures remove delegates for performance critical code, without giving an alternative. > > Please give this a high priority. > > it's better to introduce a new keyword, closure. there on heap: closure t = { // my closure return 3; } on stack: delegate t = { retirm 3; } -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

On Mon, 14 Jul 2008 04:39:58 +0200, davidl <davidl@126.com> wrote: > it's better to introduce a new keyword, closure. > > there > > on heap: > closure t = { > // my closure > return 3; > } > > on stack: > delegate t = { > retirm 3; > } Wouldn't it suffice to overload the new keyword? heap: delegate t = new { return 3; } stack: delegate t = { return 3; } That way it could work with delegate literals too: int b = 3; foo(new { return b; }); -Mike -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Mike wrote: > On Mon, 14 Jul 2008 04:39:58 +0200, davidl <davidl@126.com> wrote: > >> it's better to introduce a new keyword, closure. >> >> there >> >> on heap: >> closure t = { >> // my closure >> return 3; >> } >> >> on stack: >> delegate t = { >> retirm 3; >> } > > Wouldn't it suffice to overload the new keyword? > > heap: > > delegate t = new { return 3; } > > stack: > > delegate t = { return 3; } > > That way it could work with delegate literals too: > > int b = 3; > foo(new { return b; }); > > -Mike > > For what it's worth, I like that solution a lot.

"downs" <default_357-line@yahoo.de> wrote in message news:g5fs5j$p0d$1@digitalmars.com... >> >> Wouldn't it suffice to overload the new keyword? >> >> heap: >> >> delegate t = new { return 3; } >> >> stack: >> >> delegate t = { return 3; } >> >> That way it could work with delegate literals too: >> >> int b = 3; >> foo(new { return b; }); >> >> -Mike >> >> > > For what it's worth, I like that solution a lot. Seconded.

Reply to mike, > On Mon, 14 Jul 2008 04:39:58 +0200, davidl <davidl@126.com> wrote: > >> it's better to introduce a new keyword, closure. >> >> there >> >> on heap: >> closure t = { >> // my closure >> return 3; >> } >> on stack: >> delegate t = { >> retirm 3; >> } > Wouldn't it suffice to overload the new keyword? > > heap: > > delegate t = new { return 3; } > > stack: > > delegate t = { return 3; } > > That way it could work with delegate literals too: > > int b = 3; > foo(new { return b; }); > -Mike > I like it. a few questions: Would it only work with literals? what about nested functions? I have always thought that delegates should be able to be scope on anything you want: struct Foo { int bar; } Foo* f = new Foo; f.bar = 0; auto inc = f.new { this.bar++; } inc(); assert (f.bar==1); or even: int i = 5; auto times = i.new (int j){return this*j;} i=6; assert(times(i) == 30);

On Mon, 14 Jul 2008 19:35:53 +0400, Mike <vertex@gmx.at> wrote: > On Mon, 14 Jul 2008 04:39:58 +0200, davidl <davidl@126.com> wrote: > >> it's better to introduce a new keyword, closure. >> >> there >> >> on heap: >> closure t = { >> // my closure >> return 3; >> } >> >> on stack: >> delegate t = { >> retirm 3; >> } > > Wouldn't it suffice to overload the new keyword? > > heap: > > delegate t = new { return 3; } > > stack: > > delegate t = { return 3; } > > That way it could work with delegate literals too: > > int b = 3; > foo(new { return b; }); > > -Mike > > Shouldn't it be heap-allocated by default? I prefer scope keywork reuse :)

BCS: > > Wouldn't it suffice to overload the new keyword? > > heap: > > delegate t = new { return 3; } > > stack: > > delegate t = { return 3; } Generally in D the default behavior must be the safer one, in this situation it means the heap version... Bye, bearophile

"Koroskin Denis" <2korden@gmail.com> wrote in message news:op.ueaoscr8enyajd@proton.creatstudio.intranet... > > Shouldn't it be heap-allocated by default? I prefer scope keywork reuse :) You have a point there. And I think you may have something with using 'scope' to indicate nested functions whose stack frames are not to be heap-allocated. It goes along with scope classes nicely. You wouldn't be able to return a scope delegate, and it makes sense -- "this delegate only works in this scope. When the scope leaves, the delegate is no longer valid." Adding "scope" also makes it possible for the compiler to check that you don't do stupid things statically, at least in many cases.