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 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.

> compilation error is the only safe approach, if you do
> not wish scoped destruction, don’t request it in the first place!

Destruction is implicit and it is possible to allocate structs on the heap anyway.

> dangerous operations like this should be explicit to avoid surprises,
> not hidden in complicared implicit special cases.

If failing compilation is the way to go, avoiding special cases is not why. Erroring out here is a special case.

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 work well in a pure functional
>> setting).
>
> 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's help.
>
> BTW, the default iteration pattern in Ruby is to use blocks:
>
> [1, 2, 3].each { |e| puts e }
>
> Closest translation in D:
>
> [1, 2, 3].each!(e => writeln(e));
>
> But in D one would of course use a foreach loop instead.

Those aren't closures, it captures none of the environment. Those are just simple lambda functions.

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's help.
>>
>> BTW, the default iteration pattern in Ruby is to use blocks:
>>
>> [1, 2, 3].each { |e| puts e }
>>
>> Closest translation in D:
>>
>> [1, 2, 3].each!(e => writeln(e));
>>
>> But in D one would of course use a foreach loop instead.
>
> Those aren't closures, it captures none of the environment. Those are just simple lambda functions.

Maybe this would be a better Ruby example?

##################################################
module App
    def self.run
        register_callbacks
        Other.call_all
    end

    def self.register_callbacks
        foo = 10
        Other.register { puts foo }

        Other.register { puts self }

        foo = 20
        Other.register { puts foo }

        foo = 30
    end
end

module Other
    @@callbacks = []

    def self.register (&blk)
        @@callbacks << blk
    end

    def self.call_all
        @@callbacks.each {|cb| cb.call }
    end
end

App.run if __FILE__ == $0
##################################################

Output is:
30
App
30

-- Chris NS

Am Wed, 30 Oct 2013 13:28:12 +0100
schrieb "Max Samukha" <maxsamukha@gmail.com>:

> 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-loop-variable-considered-harmful.aspx.

Without thinking much about it, why not call loop variables temporaries that you cannot close over. If you want a closure you'd have to declare the variable either inside or outside the loop.

-- 
Marco