You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have some code for dynamically typed error handling, and to provide syntactic sugar over nested match expressions I have a macro with syntax that itself mimics a single match expression:
error_match!{(err){(a_err:DomainError<A>) => {// ...}// note no comma here(b_err:DomainError<B>) => (),// an expression followed by a comma// ...}}
There does not seem to be a way to alternate different matchers in repetition sequences, and furthermore, the current rules disallow block fragments followed by repetition sequences. So in realizing such macro recursively I'm limited to comma-appended expressions at the end of each arm, like so:
The need to put a comma after a block is annoying, as the real match statement syntax forbids commas in this position. So I'd like there to be a fragment specifier that would make the fragment match either an expression followed by a comma, or a block. The macro future-proofing rules for fragments of this type would allow them to immediately precede sequence repetition and end a repeating sequence, so the invocation pattern above could be extended as follows:
I have some code for dynamically typed error handling, and to provide syntactic sugar over nested match expressions I have a macro with syntax that itself mimics a single match expression:
There does not seem to be a way to alternate different matchers in repetition sequences, and furthermore, the current rules disallow block fragments followed by repetition sequences. So in realizing such macro recursively I'm limited to comma-appended expressions at the end of each arm, like so:
The need to put a comma after a block is annoying, as the real match statement syntax forbids commas in this position. So I'd like there to be a fragment specifier that would make the fragment match either an expression followed by a comma, or a block. The macro future-proofing rules for fragments of this type would allow them to immediately precede sequence repetition and end a repeating sequence, so the invocation pattern above could be extended as follows:
The text was updated successfully, but these errors were encountered: