Variables with scoped destruction in closures

ketmar via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sat Oct 15 00:55:30 PDT 2016


On Saturday, 15 October 2016 at 05:41:05 UTC, Walter Bright wrote:
> The problem is the closure is generated when it is expected 
> that the delegate will survive past the end of the scope (it's 
> the whole point of a closure). But with a destructor that runs 
> at the end of the scope, it cannot survive, and so the user of 
> the closure will be referring to a destroyed object.

while this is generally true, it bites me every time i'm using my 
refcounted objects. i have std.stdio.File replacement, which is 
just an rc-struct for the outside world, and i can't write 
generalized templates with it, as i'm hitting this "scoped 
destruction" issue often enough for it to be annoying. like, for 
example, when i want to accept generalized i/o stream (i have 
template checkers for that) in write[ln] replacement, so i have 
to write this abominations:

public void write(A...) (VFile fl, A args) { 
writeImpl!(false)(fl, args); }
public void write(ST, A...) (auto ref ST fl, A args) if (!is(ST 
== VFile) && isRorWStream!ST) { writeImpl!(false, ST)(fl, args); }

VFile is perfectly valid "OutputStream", but i can't use general 
template, 'cause VFile has dtor which decrements rc, and compiler 
complains. i.e. that should be just:

public void write(ST, A...) (auto ref ST fl, A args) if 
(isRorWStream!ST) { writeImpl!(false, ST)(fl, args); }

can we, please, have some way to tell the compiler that it is 
perfectly ok for some structs to have scoped destruction *and* be 
a member of closure? also, what kind of *closure* compiler tries 
to build here? it is a simple templated function, which calls 
another templated function, nothing fancy.


More information about the Digitalmars-d-learn mailing list