[moonchild]

That's not pattern matching, it's just switching on arbitrary values. You can do the same thing in d, which doesn't have pattern matching. Pattern matching is something like this:

  switch [playerA.move, playerB.move]
          case [x, x]: Tied()
          case [Rock, x]: Winner(if x == Scissors then playerA else playerB)

[RobertKerans]

It is pattern matching, the semantics are an OCaml/ML family `match` expression.

[moonchild]

Ah, so it is[0]. The GP's example doesn't require pattern matching though; as I mentioned, it would work in a language lacking it.

0. https://haxe.org/manual/lf-pattern-matching-structure.html

[yawaramin]

How so?

[moonchild]

[playerA.move, playerB.move] is an array literal value, as are [Rock, Scissors] and the other controlling expressions. The switch simply performs a direct comparison between the two; there need be no destructuring for that to work.

[yawaramin]

I meant 'how would it work in a language without pattern matching?'

Because it seems to me that it won't. E.g. try this in JavaScript right now with a regular switch statement, it doesn't work. You need actual pattern matching.

[RobertKerans]

It won't work in JS because arrays are compared by reference, so it would always fail to match (I think immutable data structures, at proposal stage 2, would provide one potential fix for this, otherwise need a workaround such as bitmasking the array before performing a match). It not working isn't simply that pattern matching isn't present in the language, per se.

[moonchild]

'It doesn't work in one particular language that happens to lack pattern matching, therefore it cannot work without pattern matching.'

In particular, pattern matching generally entails destructuring, which you do not need in order to make that particular example work.

[zem]

it works in ruby without pattern matching, thanks to ruby's switch statement design where `switch a: case b` invokes `b.match(a)`