3 ms·

> it shouldn't break fundamental rules of the language it doesn't? you simply don't understand what a match statement is. https://doc.rust-lang.org/book/ch19-

> it shouldn't break fundamental rules of the language it doesn't? you simply don't understand what a match statement is. https://doc.rust-lang.org/book/ch19-03-pattern-syntax.html https://doc.rust-lang.org/book/ch19-03-pattern-syntax.html let num = Some(4); match num { Some(x) if x % 2 == 0 => println!("The number {x} is even"), Some(x) => println!("The number {x} is odd"), None => (), } notice that x is bound to 4.

pansa2 1y ago
> you simply don't understand what a match statement is It's "a DSL contrived to look like Python, and to be used inside of Python, but with very different semantics": https://discuss.python.org/t/gauging-sentiment-on-pattern-matching/5770/21 https://discuss.python.org/t/gauging-sentiment-on-pattern-ma...
- almostgotcaught 1y ago
  you linked to a random detractors rant. i don't see what that has to do with whether a match statement binds a match?
tialaramex 1y ago
Which x? There are two in your code, one for each time you introduce a pattern Some(x) and each x has scope which of course ends when that pattern is done with Notice that the Python doesn't work this way, we didn't make a new variable but instead changed the existing one. Also, the intent in the Python was a constant, in Rust we'd give this constant an uppercase name by convention, but regardless it's a constant and so of course matching against a constant does what you expect, it can't re-bind a constant, 404 is a constant and so is `const NOT_FOUND: u16 = 404;`
- almostgotcaught 1y ago
  > Which x? There are two in your code, one for each time you introduce a pattern Some(x) and each x has scope which of course ends when that pattern is done with if each x's scope ends at the end of each case doesn't that mean there's only one x? > we didn't make a new variable but instead changed the existing one. so because python doesn't have scopes except for function scopes it shouldn't ever have any new features that intersect with scope?
  - Spivak 1y ago
    Also this is pretty much in line for the rest of Python leaving variables around. for x in [1]: pass print(x) # => 1 The match statement presented is equivalent to an assignment, you do have to know that, but then it's just regular Python.
    - instig007 1y ago
      Being in line with the bad original design decision is another bad design decision, python developers should have a courage to admit these instances to benefit from better decisions in new peps. They didn't do it with pattern matching and now the language has another inferior implementation of a feature that, if implemented correctly, should have had clear block scopes, defined as expressions (as opposed to statements), and disallowed type-diverging branches. Java has designed it right, by the way, despite having a differently behaving switch statement in the language already.
      - lou1306 1y ago
        > Being in line with the bad original design decision is another bad design decision I disagree. Consistently going with the "bad" choice (in this case, leaking the variable to the outer scope) is better inconsistently swinging between 2 ways of doing things. Least astonishment!
        tialaramex 1y ago
        "We've made this mistake before so for consistency we need to repeat it" is such a bad idea. Ideally you want a way to go back and fix things you got wrong, but, even if you can't do that (which is itself a defect and you should figure out how you can improve) you should improve as you move forward. C++ has struggled with this, so that paper authors sometimes plead with the committee not to make their proposal needlessly worse in the name of "consistency" with existing bad features. This famously failed for std::span, which thus managed to be not only a real world footgun in a language which already has plenty of footguns but also a PR footgun - because for "consistency" the committee removed the safety from the safety feature and I believe in C++ 26 they will repair this so it's just pointless rather than actively worse...

pansa2 1y ago

> you simply don't understand what a match statement is It's "a DSL contrived to look like Python, and to be used inside of Python, but with very different semantics": https://discuss.python.org/t/gauging-sentiment-on-pattern-matching/5770/21 https://discuss.python.org/t/gauging-sentiment-on-pattern-ma...

almostgotcaught 1y ago
you linked to a random detractors rant. i don't see what that has to do with whether a match statement binds a match?

tialaramex 1y ago

Which x? There are two in your code, one for each time you introduce a pattern Some(x) and each x has scope which of course ends when that pattern is done with Notice that the Python doesn't work this way, we didn't make a new variable but instead changed the existing one. Also, the intent in the Python was a constant, in Rust we'd give this constant an uppercase name by convention, but regardless it's a constant and so of course matching against a constant does what you expect, it can't re-bind a constant, 404 is a constant and so is `const NOT_FOUND: u16 = 404;`

almostgotcaught 1y ago
> Which x? There are two in your code, one for each time you introduce a pattern Some(x) and each x has scope which of course ends when that pattern is done with if each x's scope ends at the end of each case doesn't that mean there's only one x? > we didn't make a new variable but instead changed the existing one. so because python doesn't have scopes except for function scopes it shouldn't ever have any new features that intersect with scope?
- Spivak 1y ago
  Also this is pretty much in line for the rest of Python leaving variables around. for x in [1]: pass print(x) # => 1 The match statement presented is equivalent to an assignment, you do have to know that, but then it's just regular Python.
  - instig007 1y ago
    Being in line with the bad original design decision is another bad design decision, python developers should have a courage to admit these instances to benefit from better decisions in new peps. They didn't do it with pattern matching and now the language has another inferior implementation of a feature that, if implemented correctly, should have had clear block scopes, defined as expressions (as opposed to statements), and disallowed type-diverging branches. Java has designed it right, by the way, despite having a differently behaving switch statement in the language already.
    - lou1306 1y ago
      > Being in line with the bad original design decision is another bad design decision I disagree. Consistently going with the "bad" choice (in this case, leaking the variable to the outer scope) is better inconsistently swinging between 2 ways of doing things. Least astonishment!
      - tialaramex 1y ago
        "We've made this mistake before so for consistency we need to repeat it" is such a bad idea. Ideally you want a way to go back and fix things you got wrong, but, even if you can't do that (which is itself a defect and you should figure out how you can improve) you should improve as you move forward. C++ has struggled with this, so that paper authors sometimes plead with the committee not to make their proposal needlessly worse in the name of "consistency" with existing bad features. This famously failed for std::span, which thus managed to be not only a real world footgun in a language which already has plenty of footguns but also a PR footgun - because for "consistency" the committee removed the safety from the safety feature and I believe in C++ 26 they will repair this so it's just pointless rather than actively worse...