On Mon, Aug 30, 2010 at 8:56 PM, Graydon Hoare <[email protected]> wrote:
> Oh? The uses I've seen in C++ are usually somewhat descriptive, say:
>
> {
> Mutex guard(some_lock);
> do_stuff();
> }
>
> Reads ok to me. I don't imagine it being made much shorter or more succinct
> via lambdas. in Rust it'd look like so (assuming locking some external
> resource, since of course, inter-thread locking isn't quite a standard
> consideration in Rust code :) :
>
> {
> auto guard = mutex(some_lock);
> do_stuff();
> }
>
> A bit longer than C++, but then, also no potential parse ambiguity. And I
> think still clear. What's the putative lambda-like form?
>
> with_mutex(some_lock,
> fn() {
> do_stuff();
> })
>
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). Plus, it doesn't require declaring a
dummy variable (you call it "guard", others call it "dummy", or "locker").
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).
I guess the reason I dislike RAII for this type of things is partly that it
adds an extra name that's not needed for anything to the namespace which
just feels untidy, and that it looks like just another variable. You'd have
to be very careful to understand that this variable is actually "special".
With a lambda it's clear that you're passing that whole block of code to
some *other* function declared elsewhere and that you should probably look
up what that function does with your lambda before you add stuff to it
willy-nilly.
Anywyay, aesthetics of RAII-like constructs isn't really the main point, it
was only ever intended as one example. You can have the *ability* to write
the latter form and choose not to use it if you don't like it. There would
still be plenty of other cases where having the ability to use lambdas as a
"first class scope" is useful even if you opt out of one specific case (as
I'm sure your nearest Lisper will be all to happy to tell you!).
You may want to consider a "scope" feature like D has, which allows you to
>> put code at the end of the current scope (regardless of how it leaves it).
>> My "transaction" example would work just as well, better actually, and
>> would certainly be a lot cleaner than with the try/finally stuff in there.
>>
>
> It's not the association-with-a-scope-exit aspect that's hard to get right.
> It's the initialization-status-tracking.
>
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.
In this particular case we didn't even bother creating a "with_lock"
function but could still attach arbitrary cleanup code to the end of the
scope, which is quite convenient for all the times you just need some quick
custom code to run at the end of the scope. Having to introduce a new class,
and a new variable for that is a bit burdensome IMO.
I realise I'm arguing for a brand new feature here though, which is
obviously a cardinal sin :-)
I'm not entirely sold on the scope feature in D, btw, but I can see its
usefulness in that it alleviates some of the burden associated with
scope-based resource management that you get with RAII.
--
Sebastian Sylvan
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
