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
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to