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