www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Opt-out closures

reply Sean Eskapp <eatingstaples gmail.com> writes:
I get errors when working with nested functions and structs or scoped classes,
because closures can't be used with anything with scoped destruction. This
makes complete sense, but I don't even want the closure functionality of these
nested functions. Personally, I would like to be able to opt-out of the
closure functionality of nested functions: if the enclosing function exits,
and a nested function thereof is called, then a segfault would occur when it
tried to access the stack of its enclosing function; however, access of
scoped-destruction variables from an enclosing-scope function would be fine.

Thoughts? The not-being-able-to-access-scoped-destruction-variables thing is
really getting to me, since one of the main driving features I like about D is
the ability to use anonymous and nested functions.
Jan 23 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 23 January 2011 06:36:27 Sean Eskapp wrote:

 I get errors when working with nested functions and structs or scoped
 classes, because closures can't be used with anything with scoped
 destruction. This makes complete sense, but I don't even want the closure
 functionality of these nested functions. Personally, I would like to be
 able to opt-out of the closure functionality of nested functions: if the
 enclosing function exits, and a nested function thereof is called, then a
 segfault would occur when it tried to access the stack of its enclosing
 function; however, access of scoped-destruction variables from an
 enclosing-scope function would be fine.
 
 Thoughts? The not-being-able-to-access-scoped-destruction-variables thing
 is really getting to me, since one of the main driving features I like
 about D is the ability to use anonymous and nested functions.


If a nested function is marked as static, then it results in a function rather 
than a delegate. Of course, that means that you can't access the enclosing 
scope, but if you don't care about that, then just use static.

- Jonathan M Davis
Jan 23 2011
parent reply Sean Eskapp <eatingstaples gmail.com> writes:
== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article

 On Sunday 23 January 2011 06:36:27 Sean Eskapp wrote:

 I get errors when working with nested functions and structs or scoped
 classes, because closures can't be used with anything with scoped
 destruction. This makes complete sense, but I don't even want the closure
 functionality of these nested functions. Personally, I would like to be
 able to opt-out of the closure functionality of nested functions: if the
 enclosing function exits, and a nested function thereof is called, then a
 segfault would occur when it tried to access the stack of its enclosing
 function; however, access of scoped-destruction variables from an
 enclosing-scope function would be fine.

 Thoughts? The not-being-able-to-access-scoped-destruction-variables thing
 is really getting to me, since one of the main driving features I like
 about D is the ability to use anonymous and nested functions.


 If a nested function is marked as static, then it results in a function rather
 than a delegate. Of course, that means that you can't access the enclosing
 scope, but if you don't care about that, then just use static.
 - Jonathan M Davis


I want to be able to access the enclosing scope, but NOT after the function has
exited; I should have the option of accessing the enclosing scope, but at the
cost
of making my delegate not a closure.
Jan 23 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Eskapp:


 I want to be able to access the enclosing scope, but NOT after the function has
 exited; I should have the option of accessing the enclosing scope, but at the
cost
 of making my delegate not a closure.


It seems a worth thing to ask for. A possible syntax (not currently supported):

void foo() {
    scope void bar() {}
}

Bye,
bearophile
Jan 23 2011
next sibling parent Sean Eskapp <eatingstaples gmail.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 Sean Eskapp:

 I want to be able to access the enclosing scope, but NOT after the function has
 exited; I should have the option of accessing the enclosing scope, but at the
cost
 of making my delegate not a closure.


 It seems a worth thing to ask for. A possible syntax (not currently supported):
 void foo() {
     scope void bar() {}
 }
 Bye,
 bearophile


That looks like one of the best options syntax-wise. Nice!
Jan 23 2011
prev sibling next sibling parent Andrew Wiley <debio264 gmail.com> writes:
On Sun, Jan 23, 2011 at 9:08 AM, bearophile <bearophileHUGS lycos.com>wrote:


 Sean Eskapp:


 I want to be able to access the enclosing scope, but NOT after the


 function has

 exited; I should have the option of accessing the enclosing scope, but at


 the cost

 of making my delegate not a closure.


 It seems a worth thing to ask for. A possible syntax (not currently
 supported):

 void foo() {
    scope void bar() {}
 }


I don't like being too negative, but if we're removing "scope" as a storage
class because it can leave unsafe dangling pointers, how likely is it that
we'll get delegates that can have dangling pointers?
Jan 23 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-23 16:08, bearophile wrote:

 Sean Eskapp:


 I want to be able to access the enclosing scope, but NOT after the function has
 exited; I should have the option of accessing the enclosing scope, but at the
cost
 of making my delegate not a closure.


 It seems a worth thing to ask for. A possible syntax (not currently supported):

 void foo() {
      scope void bar() {}
 }

 Bye,
 bearophile


Doesn't D2 have scoped delegates, at last as a parameter to a function?

-- 
/Jacob Carlborg
Jan 23 2011
prev sibling parent reply Torarin <torarind gmail.com> writes:
2011/1/23 Sean Eskapp <eatingstaples gmail.com>:

 I want to be able to access the enclosing scope, but NOT after the function has
 exited; I should have the option of accessing the enclosing scope, but at the
cost
 of making my delegate not a closure.


Until we have a dedicated syntax for it, I think you can use this hack:

import std.traits;

auto scopeDelegate(D)(scope D d) if (isDelegate!D)
{
  return d;
}

int main()
{
   StructWithDtor s;
   trustedFunction(scopeDelegate({s.a = 5;}); // No heap allocation
}


Torarin
Jan 23 2011
parent Sean Eskapp <eatingstaples gmail.com> writes:
== Quote from Torarin (torarind gmail.com)'s article

 2011/1/23 Sean Eskapp <eatingstaples gmail.com>:

 I want to be able to access the enclosing scope, but NOT after the function has
 exited; I should have the option of accessing the enclosing scope, but at the
cost
 of making my delegate not a closure.


 Until we have a dedicated syntax for it, I think you can use this hack:
 import std.traits;
 auto scopeDelegate(D)(scope D d) if (isDelegate!D)
 {
   return d;
 }
 int main()
 {
    StructWithDtor s;
    trustedFunction(scopeDelegate({s.a = 5;}); // No heap allocation
 }
 Torarin


Yup, works great with everything I've tried! Thanks.
Jan 23 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrew Wiley:


 I don't like being too negative, but if we're removing "scope" as a storage
 class because it can leave unsafe dangling pointers, how likely is it that
 we'll get delegates that can have dangling pointers?


I have written that without too much thinking, so I'm sure that's not a perfect
idea :-)

Regarding "scope" for classes, it is deprecated, instead of improving it, but
the currently alternative solution is _less_ safe than the scope, and it's more
buggy:
http://d.puremagic.com/issues/show_bug.cgi?id=5115

A Java VM like the Oracle one has the best GC, plus escape analysis that allows
it to stack-allocate some class instances. Currently D compilers have a far
worse GC and even LDC-LLVM escape analysis is weak and it doesn't do much for D
class instances.

In my opinion D and its compilers need to perform that stack optimization by
themselves, or the programmer needs to be "empowered" with some good, efficient
and as much safe as possible way to stack allocate a class instance. At the
moment D has none of both. Good luck with a slow system language :-)

Bye,
bearophile
Jan 23 2011