On 12-10-22 02:12 AM, Benjamin Striegel wrote:
> Could the RAII-styled second option be rewritten as follows?
>
> do |cond, handler| {
> cond.add(handler);
> do_some_stuff();
> that_might_raise();
> out_of_kittens();
> }(OutOfKittens) |t| {
> UseAardvarksInstead
> }
Not with that syntax, no.
I gather the overall aim in most of these responses is to reduce the use
of () rather than {} wherever possible, and to support multiple handlers
stacked in a row, rather than requiring a separate block per handler;
but the fact is we have no support for multiple blocks in do-notation
right now, so at best this turns into some kind of
accumulate-into-a-heap-vec hack that is costly and fragile and .. still
doesn't get you into braces.
We could conceivably add a multi-brace form to 'do', but that would be a
different matter (also one I'm not sure about the correct translation
of). For example, supposing we supported:
do foo |a, b, c| {
...
} bar |d, e, f| {
...
} baz |g, h, i| {
...
}
It is unclear to me whether this is best parsed as:
foo(|a, b, c| ...,
bar(|d, e, f| ...,
baz(|g, h, i| ...)))
or
baz(|g, h, i| ...,
bar(|d, e, f| ...,
foo(|a, b, c| ...)))
or
foo(|a, b, c| ...).bar(|d, e, f| ...).baz(|g, h, i| ...)
or
baz(|g, h, i| ...).bar(|d, e, f| ...).foo(|a, b, c ...)
In any case, the handler-before-protected vs. protected-before-handler
question is orthogonal, and while I'm sympathetic to "going with
tradition" (handlers after) the implementation involves delaying the
code until destruction of a temporary, which is just a bit too
unintuitive for me to feel good about, and also removes the possibility
of returning a value (the value has to be written via environment
capture to an option in the environment, say).
I think I'll go with #3 at this point and fix the remaining
implementation-blocking bugs. Worst case we can revisit -- possibly
build a multi-block syntax like above, as I can see other cases it'd be
nice -- but I think #3 will work well enough for now and there's other
stuff to do.
Thanks,
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
