Feature request: bigger enclosing block to use guards in bulk.

[vi]

I want to write something like

guard_block! {
    let Some(b) = a else { return; }
    let Some(c) = b else { return; }
    foo(&c);
    let Some(d) = c else { return; }
}

instead of encasing everything in additional level of parenthesis:

guard!(let Some(b) = a else { return; });
guard!(let Some(c) = b else { return; });
foo(&c);
guard!(let Some(d) = c else { return; });

guard_block! { guard let Some(b) = a else { return; } } is fine too.

[vi]

Also would it better be a proc macro instead of declarative?

The code looks tricky.

[durka]

This is ambiguous (one of the reasons the syntax was controversial in the RFC):

guard_block! {
    let x = if y { z } else { panic!() };
}

Is it a regular let or a guard-let? However, a block form with guard let statements seems doable.

I like tricky declarative macros!

[vi]

Why is this crate unpopular (no reverse deps, few downloads), e.g. compared to if_chain?

Possible reasons:

• Nobody needs guard lets; or
• There is competitor crate that is popular; or
• This crate works poorly; or
• There is some typical workaround everybody use?

[durka]

I think it's probably just not that common a use case combined with lack of marketing. I basically made this crate as a proof of concept during the RFC. On further investigation it seems that macro_rules limitations prevent guard_block from working. I'll consider a procedural macro approach.

…

On Mon, Apr 22, 2019 at 4:14 AM Vitaly Shukela ***@***.***> wrote: Why is this crate unpopular (no reverse deps, few downloads), e.g. compared to if_chain? Possible reasons: - Nobody needs guard lets; or - There is competitor crate that is popular; or - This crate works poorly; or - There is some typical workaround everybody use? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAALPHYYWQCF2GRJPFR73Q3PRVXUPANCNFSM4HHDVNHA> .