On 10-08-30 02:10 PM, Sebastian Sylvan wrote:
I'd prefer this last option because it makes it very clear that the scope is
"attached" to the mutex, so people will hopefully not add extra stuff to
that scope by accident (since it's extremely important that the scope is
kept minimal if you're holding a lock)
Fair. As I said though, this is turning into more of an aesthetic
argument. We're going to keep some kind of destructor-y thing for
long-lived objects -- or clean-up lists, or something! -- so let's focus
on discussing down-lambdas for other uses, for now.
Also, you get more control over that lambda, e.g. you could declare, by its
type, that it needs to be pure (for things like parallel_for).
Yes, absolutely. I'm not denying the potential for other things that
happen to make use of down-lambdas. We seem to have got a bit
side-tracked on the RAII topic :)
Maybe it'd be helpful to open an emacs buffer and write down some
use-cases for purely down-lambdas, see what would work and how. I'll
post a bit more on this momentarily as there's a crossed-wires thing
going on here with what dherman's proposing. Not bad, just different.
I'm not 100% sure, my D book is at work and I'm not, but I believe the scope
statement (incredibly hard to search for, btw!) only applies once you've
actually hit that point of execution. So it's only once you hit the "scope"
statement that it gets "activated". Which means you'd put it right after the
initialization of something to indicate that it's going to be cleaned up at
the end of the scope. E.g.
foo();
bar();
some_lock.lock();
scope (exit) some_lock.unlock();
baz();
If execution fails in foo, or bar (or even in the some_lock.lock()) nothing
happens at the end of the scope, only if it fails in baz does it actually
unlock the lock.
Ah, then this is like the 'defer' statement in Go (or the 'rescue'
blocks of its ancestor language, Alef). Sorry, I should study D more; I
know it's got more to teach me than I've given it attention. I have
looked at it a *bit* ... but not lately, and not deep enough or in light
of the past few years of Rust hacking.
I realise I'm arguing for a brand new feature here though, which is
obviously a cardinal sin :-)
Sure. Though of course these can be simulated in library code if you
have RAII and closures:
{
auto exit = cleanup();
foo();
bar();
some_lock.lock();
exit.add(bind fn(lock lk) { lk.unlock(); }(some_lock));
baz();
}
Though this is plainly not the tidiest code sample we've tossed back and
forth today. I accept that if we're going to lean on function literals
hard for helper-y things, we're going to have to spend some time making
them less chatty. See next email exchange with dherman :)
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
