Am Wed, 30 Oct 2013 13:28:12 +0100
schrieb "Max Samukha" :
> On Wednesday, 30 October 2013 at 12:17:29 UTC, Max Samukha wrote:
>
> > So D managed to mess up closures, too. And that's after years
> > of countless complaints about the same issue in JS!
>
> And please no misguided arguments like
On Thursday, 31 October 2013 at 20:56:11 UTC, Peter Alexander
wrote:
On Thursday, 31 October 2013 at 07:41:30 UTC, Jacob Carlborg
wrote:
I use Ruby all day with a lot of blocks (closures) and I never
had any problem. In Ruby everything is an object and passed
around by reference. I guess that
On Thursday, 31 October 2013 at 07:41:30 UTC, Jacob Carlborg
wrote:
On 2013-10-30 21:35, Peter Alexander wrote:
I think not running the destructor is the best option
(although to be
honest, I'm not a huge fan of closures to begin with, for
exactly these
sorts of reasons -- they only really wor
On 10/31/2013 01:46 AM, Xiaoxi wrote:
=
The combination of closure variables + scoped destruction should
be rejected, but currently it isn't. It's a compiler bug.
http://d.puremagic.com/issues/show_bug.cgi?id=11382
Kenji Hara
=
Ali
kenji is right.
I think nobody is 'right' here.
On Thursday, 31 October 2013 at 07:41:30 UTC, Jacob Carlborg
wrote:
But in D one would of course use a foreach loop instead.
I think `std.algorithm.copy` is generally a good replacement for
foreach loops in functional D code.
On 2013-10-30 21:35, Peter Alexander wrote:
I think not running the destructor is the best option (although to be
honest, I'm not a huge fan of closures to begin with, for exactly these
sorts of reasons -- they only really work well in a pure functional
setting).
I use Ruby all day with a lot
On Thursday, 31 October 2013 at 00:46:05 UTC, Xiaoxi wrote:
On Wednesday, 30 October 2013 at 21:15:37 UTC, Ali Çehreli
wrote:
On 10/29/2013 10:55 AM, Ali Çehreli wrote:
> Continuing the conversation from the following thread:
>
> http://forum.dlang.org/post/l4mi8l$1r1$1...@digitalmars.com
Ke
On Wednesday, 30 October 2013 at 21:15:37 UTC, Ali Çehreli wrote:
On 10/29/2013 10:55 AM, Ali Çehreli wrote:
> Continuing the conversation from the following thread:
>
>http://forum.dlang.org/post/l4mi8l$1r1$1...@digitalmars.com
Kenji Hara added there:
=
The combination of closure vari
On Wednesday, 30 October 2013 at 20:35:14 UTC, Peter Alexander
wrote:
I think not running the destructor is the best option (although
to be honest, I'm not a huge fan of closures to begin with, for
exactly these sorts of reasons -- they only really work well in
a pure functional setting).
I d
On 10/29/2013 10:55 AM, Ali Çehreli wrote:
> Continuing the conversation from the following thread:
>
>http://forum.dlang.org/post/l4mi8l$1r1$1...@digitalmars.com
Kenji Hara added there:
=
The combination of closure variables + scoped destruction should
be rejected, but currently it isn
On 10/30/2013 10:56 AM, David Nadlinger wrote:
On Wednesday, 30 October 2013 at 09:20:40 UTC, Lionello Lunesu wrote:
Why? It's a struct. It should be completely fine to create a copy [on
the heap] for the closure context
That's definitely not how D closures work, they always refer to local
var
On Wednesday, 30 October 2013 at 09:20:40 UTC, Lionello Lunesu
wrote:
On 10/29/13, 22:42, David Nadlinger wrote:
On Tuesday, 29 October 2013 at 21:41:25 UTC, Lionello Lunesu
wrote:
So a copy should have been made of the live object, not the
destructed
one. Correct?
No. There should only be o
On Wednesday, 30 October 2013 at 07:49:48 UTC, Jacob Carlborg
wrote:
On 2013-10-29 22:57, Ali Çehreli wrote:
Imagine someone decides to return a lambda from foo() instead:
auto foo()
{
S s = S(1);
return {};// <-- Should 's' be immortal now?
}
Too subtle for my taste! :)
Of cour
On Wednesday, 30 October 2013 at 12:28:13 UTC, Max Samukha wrote:
On Wednesday, 30 October 2013 at 12:17:29 UTC, Max Samukha
wrote:
So D managed to mess up closures, too. And that's after years
of countless complaints about the same issue in JS!
And please no misguided arguments like
http:/
On Wednesday, 30 October 2013 at 12:17:29 UTC, Max Samukha wrote:
So D managed to mess up closures, too. And that's after years
of countless complaints about the same issue in JS!
And please no misguided arguments like
http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closing-over-the-lo
On Wednesday, 30 October 2013 at 09:56:08 UTC, David Nadlinger
wrote:
One other place where this tends to crop is for code involving
loop variables, but while the behavior might be unexpected to
some, discussion has made clear that the code works as intended:
---
void main() {
import std.s
On 10/30/13, 10:56, David Nadlinger wrote:
---
void main() {
import std.stdio;
void delegate()[] dgs;
foreach (i; 0 .. 5) dgs ~= { writeln(i); };
foreach (dg; dgs) dg();
}
---
If structs behaved like you want them to, the snippet would (have to)
print 0, 1, 2, 3, 4 as well,
Did N
On Wednesday, 30 October 2013 at 09:20:40 UTC, Lionello Lunesu
wrote:
Why? It's a struct. It should be completely fine to create a
copy [on the heap] for the closure context
That's definitely not how D closures work, they always refer to
local variables "by reference".
One other place where
On 10/29/13, 22:42, David Nadlinger wrote:
On Tuesday, 29 October 2013 at 21:41:25 UTC, Lionello Lunesu wrote:
So a copy should have been made of the live object, not the destructed
one. Correct?
No. There should only be one struct instance, the one living (forever)
in the closure context.
Da
On 2013-10-29 22:57, Ali Çehreli wrote:
Imagine someone decides to return a lambda from foo() instead:
auto foo()
{
S s = S(1);
return {};// <-- Should 's' be immortal now?
}
Too subtle for my taste! :)
Of course not. "s" is never referred to in the returned delegate.
--
/Jaco
On Tuesday, 29 October 2013 at 21:57:25 UTC, Ali Çehreli wrote:
On 10/29/2013 02:41 PM, David Nadlinger wrote:
> Closures follow the infinite lifetime model – the struct
scope is never
> left, if you want.
Agreed but the implicit nature of things is troubling. Imagine
that the program depends
On 10/29/2013 02:41 PM, David Nadlinger wrote:
> Closures follow the infinite lifetime model – the struct scope is never
> left, if you want.
Agreed but the implicit nature of things is troubling. Imagine that the
program depends on the destructor to be called:
void foo()
{
auto s = S(1);
On 10/29/13, 22:37, Ali Çehreli wrote:
To add to that, Maxim Fomin notes in the D.learn forum that there are
the following conflicting requirements:
So a copy should have been made of the live object, not the destructed
one. Correct?
Sounds like the destruction and the copy are happening in
On Tuesday, 29 October 2013 at 21:41:25 UTC, Lionello Lunesu
wrote:
So a copy should have been made of the live object, not the
destructed one. Correct?
No. There should only be one struct instance, the one living
(forever) in the closure context.
David
On Tuesday, 29 October 2013 at 21:37:43 UTC, Ali Çehreli wrote:
To add to that, Maxim Fomin notes in the D.learn forum that
there are the following conflicting requirements:
1) need to allocate struct into heap due to lambda
2) need to put dtor invocation in the end as usual.
The first one is
On 10/29/2013 02:32 PM, David Nadlinger wrote:
> The problem with the compiler behavior for the code in question is that
> it destructs a live object, and thus clearly breaks the type system.
>
> I think the only correct resolution is to not destruct the object at the
> end of foo() – which incid
On Tuesday, 29 October 2013 at 21:14:39 UTC, qznc wrote:
Returning closures with reference to stack memory is a bad
idea. Maybe @safe should prohibit this?
According to http://dlang.org/function.html
"The stack variables referenced by a nested function are still
valid even after the function
On Tuesday, 29 October 2013 at 21:14:39 UTC, qznc wrote:
{ writeln(s); } // creates closure with reference to stack
memory "&s"
return ... // returns and destroys local variable s, i is now
666
foo()() // calls closure with reference to invalid memory "&s"
That's not how closures work in D –
http://dlang.org/function.html
The stack variables referenced by a nested function are still
valid even after the function exits (this is different from D
1.0). This is called a closure.
On Tuesday, 29 October 2013 at 17:55:45 UTC, Ali Çehreli wrote:
Continuing the conversation from the following thread:
http://forum.dlang.org/post/l4mi8l$1r1$1...@digitalmars.com
(Note: The OP's example there behaves as expected on git head.)
The programmer thinks that the following delegate
On 10/29/2013 01:23 PM, Jacob Carlborg wrote:
Shouldn't "s" be moved to the heap and not destroyed.
We are waiting for Walter to say the same thing and Kenji Hara to fix it
last month. ;)
Ali
On 10/29/2013 12:02 PM, Craig Dillabaugh wrote:
> the Beast will be thrown into a lake of fire and brimstone.
>
> That may explain the repeated destruction of s :o)
That's awesome! :)
Ali
On 2013-10-29 18:55, Ali Çehreli wrote:
Continuing the conversation from the following thread:
http://forum.dlang.org/post/l4mi8l$1r1$1...@digitalmars.com
(Note: The OP's example there behaves as expected on git head.)
The programmer thinks that the following delegate returned by foo() will
On Tuesday, 29 October 2013 at 17:55:45 UTC, Ali Çehreli wrote:
Continuing the conversation from the following thread:
http://forum.dlang.org/post/l4mi8l$1r1$1...@digitalmars.com
(Note: The OP's example there behaves as expected on git head.)
The programmer thinks that the following delegate
Continuing the conversation from the following thread:
http://forum.dlang.org/post/l4mi8l$1r1$1...@digitalmars.com
(Note: The OP's example there behaves as expected on git head.)
The programmer thinks that the following delegate returned by foo() will
print S(1) because the delegate uses the
35 matches
Mail list logo
