Pattern matching bug: wildcard pattern does not match tuple

[hummy123]

A potential bug was mentioned on Discord earlier this week so I went ahead and confirmed the bug actually does occur, and thought it was a good idea to record here so it's not forgotten later.

The following code (provided by Stachu, with some minimal edits applied after) demonstrates the bug:

// <test>
// does _ wildcard pattern match a DU that has a tuple?

// result: matches string "not expected"
// even though "expected" case is meant to match because of wildcard
type DU = | A | B of Bool * Bool

(match DU.B (true, false) with
  | A -> "nope"
  | B _ -> "expected"
  | B (_, _) -> "not expected") = "expected"
// </test>

I have a permalink on my fork which adds an Expecto test to run/confirm the bug, but it's likely easier to copy-paste the buggy code into one's own local copy.

[StachuDotNet]

Broadening the topic slightly: I think the core issue/limitation here is that we don't have any special representations for "wildcard pattern," either for let or match.
See LibExecution/ProgramTypes.fs, LetPattern and MatchPattern.

If you have code like let _something = 1, it's just recorded as an LPVariable, and similarly a MPVariable for match.
The intention was to eventually support LPWildcard or LPIgnored (or some better name...)

Some questions we need to answer before getting deep into impl:

• what should happen if you try to use _something, after it's been declared by a let or captured by a match? Should it work? Should we get a NotFound error of some sort? F# allows you to use such without any issue.
• (related) are there PT2RT and/or Interpreter considerations to keep in mind here? If we chose to not support referencing a _something, there are probably 'optimizations' we could make in both, but I suppose that'd be surprising?
• what do other adjacent languages (OCaml, Elm, etc) do?

---

OK, so bringing it back to the actual scenario at hand:
If/when we have a wildcard/ignore match pattern, would that fix our issue?
I think that would basically have this result in MPEnum with a single MPWild 'field'.
So, I think this would help the situation, as we could make a minor adjustment in the interpreter to account for this.
i.e` in

  | MPEnum(caseName, fields), DEnum(_, _, _, caseNameActual, fieldsActual) ->
    if caseName = caseNameActual then rList fields fieldsActual else false, []

we'd have to have another check here, and maybe bypass the normal logic if "there's only 1 field and it's a wild/ignore"?

I don't love that solution (adding complications for the special case) so worth thinking through.