Wildcard character in pattern matches with discriminated unions should raise an error if there is no field to match

[abelbraaksma]

If a discriminated union case doesn't define a field, then a wildcard used in a matching pattern should raise an error, just as a variable reference would.

Repro steps

Consider the type:

type Help =
    | Today
    | Tomorrow

And the module:

module HelpMod =
    let helpWhen =
        function
        | Today  -> "help me Today!"
        | Tomorrow -> "help me Tomorrow!"

Now consider the following module:

// compiles just fine, but shouldn't
module HelpMod =
    let helpWhen =
        function
        | Today _ -> "help me Today!"
        | Tomorrow  _ -> "help me Tomorrow!"

And compare that with this:

// fails to compile: FS0019: This constructor is applied to 1 argument(s) but expects 0
module HelpMod =
    let helpWhen =
        function
        | Today  x -> "help me Today!"
        | Tomorrow x -> "help me Tomorrow!"

Expected behavior

Neither should compile. The wildcard character is not ignorable. Compare, for instance, fun _ -> true, this is the same as fun a -> true. While the wildcard is more flexible in pattern matching, it is a replacement character for something, but here it seems to replace nothingness, which doesn't exist in F# (it isn't even unit here).

Actual behavior

The example with the wildcard compiles (but I think it shouldn't).

Known workarounds

None. Unless a workaround is to ignore this. But I think it is a syntax error that is ignored by the compiler.

Related information

Using F# 4.0, .NET 4.6 (didn't test with other .NET versions) with VS2015 Update 3.

[matthid]

While I kind of agree from a purist standpoint I think I haved used this particular "feature" while using multi line editing. It is kind of nice that you can replace everything with a wildecard, even nothing...

[dsyme]

In this particular case we will leave as is (i.e. not regard it as a bug). Feel free to raise this as a language suggestion (currently on http://fslang.uservoice.com)

[abelbraaksma]

Thanks.

No, I don't think it is worth its while to turn this into a language suggestion. I see now that in 7.0 in the language spec the pattern definition is declared recursively, which (given I understand it correctly) appears to allow this syntax (I thought originally it was a syntax error).

So, I'm ok with this disposition :).

[abelbraaksma]

May be fixed by #14055.

[abelbraaksma]

Yep, fixed indeed! In #14055.