I think you made the right decision about 'return'. btw, if you're also changing 'alt', why 'match' rather than something more familiar to C programmers like 'switch'?
Also, did you consider pythonic 'and' and 'or' keywords? Typing 'or' requires fewer keystrokes than || (and 'and' requires no more than &&). Plus, neither requires any shifting! I know Rust developers are lazy typists. ;)
Also, more readable. Personally, I think it's sad that Rust (along other systems-oriented languages like D and Go) haven't taken more of the syntax from Python, which I find to be superior to the world of curly braces.
Agreed. Especially since Rust uses a lot of different sigils already (@ , ~, &, ::, <>, || for closures...). Using and/or, hopefully along with significant whitespace would reduce the visual clutter.
Sometimes I'm a little sad about && and || as well (I'm a Python guy myself) but I get that Rust is trying to target C++ programmers first and foremost, and a little bit of familiarity goes a long way towards comforting newcomers. And judging by the number of self-proclaimed Python programmers lurking in in #rust (including at least one quite famous one), it hasn't been a complete turn-off.
Then again, the "C familiarity" rationale would seem to contradict the choice of `match` over `switch`, though I think pattern-matching is a sufficiently big deal to warrant a distinct keyword. It's an interesting comparison to Rust's old `tag` keyword, which was finally changed to `enum` because the easiest way to explain it was "look, they're basically C enums, but better". Personally I think the keyword should have remained `tag`, but you can't win 'em all. :)
Comments
I think you made the right decision about 'return'. btw, if you're also changing 'alt', why 'match' rather than something more familiar to C programmers like 'switch'?
Also, did you consider pythonic 'and' and 'or' keywords? Typing 'or' requires fewer keystrokes than || (and 'and' requires no more than &&). Plus, neither requires any shifting! I know Rust developers are lazy typists. ;)
Also, more readable. Personally, I think it's sad that Rust (along other systems-oriented languages like D and Go) haven't taken more of the syntax from Python, which I find to be superior to the world of curly braces.
Agreed. Especially since Rust uses a lot of different sigils already (@ , ~, &, ::, <>, || for closures...). Using and/or, hopefully along with significant whitespace would reduce the visual clutter.
Sometimes I'm a little sad about && and || as well (I'm a Python guy myself) but I get that Rust is trying to target C++ programmers first and foremost, and a little bit of familiarity goes a long way towards comforting newcomers. And judging by the number of self-proclaimed Python programmers lurking in in #rust (including at least one quite famous one), it hasn't been a complete turn-off.
Then again, the "C familiarity" rationale would seem to contradict the choice of `match` over `switch`, though I think pattern-matching is a sufficiently big deal to warrant a distinct keyword. It's an interesting comparison to Rust's old `tag` keyword, which was finally changed to `enum` because the easiest way to explain it was "look, they're basically C enums, but better". Personally I think the keyword should have remained `tag`, but you can't win 'em all. :)
It's named after the alternation style used, which is well established in other languages.