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.



 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.



 void foo() {
     scope void bar() {}
 }
 Bye,
 bearophile



That looks like one of the best options syntax-wise. Nice!
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 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.



 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 next sibling parent Andrew Wiley <debio264 gmail.com> writes:
--001636c5b558513928049a86e5c4
Content-Type: text/plain; charset=ISO-8859-1

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




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




 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() {}
 }



class because it can leave unsafe dangling pointers, how likely is it that
we'll get delegates that can have dangling pointers?

--001636c5b558513928049a86e5c4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, Jan 23, 2011 at 9:08 AM, bearoph=
ile <span dir=3D"ltr">&lt;<a href=3D"mailto:bearophileHUGS lycos.com">bearo=
phileHUGS lycos.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">
Sean Eskapp:<br>
<div class=3D"im"><br>
&gt; I want to be able to access the enclosing scope, but NOT after the fun=
ction has<br>
&gt; exited; I should have the option of accessing the enclosing scope, but=
 at the cost<br>
&gt; of making my delegate not a closure.<br>
<br>
</div>It seems a worth thing to ask for. A possible syntax (not currently s=
upported):<br>
<br>
void foo() {<br>
 =A0 =A0scope void bar() {}<br>
}<br>
<font color=3D"#888888"><br></font></blockquote><div><br></div><div>I don&#=
39;t like being too negative, but if we&#39;re removing &quot;scope&quot; a=
s a storage class because it can leave unsafe dangling pointers, how likely=
 is it that we&#39;ll get delegates that can have dangling pointers?=A0</di=
v>
</div><br>

--001636c5b558513928049a86e5c4--
Jan 23 2011
prev sibling parent 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