Looking for feedback on a Pre-RFC for new ‘loop/for/else match’ constucts, in particular from anyone who might want to add a description of the implementation details in the compiler. I wouldn’t expect this to go in pre-1.0, but I think it would be a nice ergonomic addition to the language.
My personal opinion: when I’m attacking a serious problem by making the most of the power of Rust, I will probably not care if I need two extra lines per loop or not… For easier problems I can crank out Ruby or Python scripts 
maybe in alternatives , you could suggest additions to the macro system
Imagine if macros could be invoked like this:
some_iterator.loop_match! (x) { // $self=some iterator.
Foo(x)=>{...}
Bar(x)=>{...}
}
basically the suggestion is “method macros” plus multiple macro parameter brackets (){} afterward to look like function signatures or other control-flow structures in C, and read more naturally with less nesting in more complex invocations.
cfor!(init; cond; incr ) {
body..
}I think the rightward drift is a bigger problem than the extra lines, but you’re right, this is definitely not a make-or-break feature for the language. Nice-to-haves are still nice to have, though.
Why no if <condition> match or while <condition> match? if let and while let aren’t replacements, as they simply change their conditions to single pattern matches. I don’t think these ... match expressions should be considered related to if let and while let, because they work quite differently. Sometimes I’ve thought that for let could be useful: for let i @ 'a' ... 'z' in iterator would iterate over iterator so long as the value yielded continued to be a lowercase (Latin) letter.
I think that these constructs could be useful to remove nesting in some places, but the places they are useful seem strangely specific.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.