Incomplete pattern matching in calculation expression

[xp44mm]

I propose we ... (describe your suggestion here)

    let fullArgs =
        [
            match maybePrototypeCtor with Some ctor -> yield ctor // | None -> ()
            yield! otherArgs
        ]

The existing way of approaching this problem in F# is ...

    let fullArgs =
        [
            match maybePrototypeCtor with Some ctor -> yield ctor | None -> ()
            yield! otherArgs
        ]

Pros and Cons

The advantages of making this adjustment to F# are ...

The disadvantages of making this adjustment to F# are ...

Extra information

Estimated cost (XS, S, M, L, XL, XXL):

Related suggestions: (put links to related suggestions here)

Affidavit (please submit!)

Please tick these items by placing a cross in the box:

• [ ] This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
• [ ] This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
• [ ] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it
• [ ] I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

• [ ] This is not a breaking change to the F# language design
• [ ] I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the :+1: emoji on this issue. These counts are used to generally order the suggestions by engagement.

[TheJayMann]

I'm assuming you mean computation expression, given I see no calculations in your example.

Given that in a list expression, a seq expression, an array expression, and computation expressions in general, a yield expression returns unit, it does allow an if expression to not require an else as when the then expression returns unit, the else expression is assumed to be (). It sounds to me that the suggestion above could be generalized to allow match expressions in general to not require exhaustive pattern matching if the expression itself is typed unit, though it could be the opinion of many that it is much more beneficial when being used within a computation expression, and possibly only with specific operations such as return or yield, such that it should only be enabled with computation expressions.

That said, I don't believe I have a preference for this suggestion, as I can see many benefits for adding this change, while also seeing many detriments. One such being that many people likely rely on match expressions warning on incomplete patterns in general and make use of warning messages to notify areas where match expressions need to be modified when a type signature is augmented.

[smoothdeveloper]

with #705

let fullArgs =
    [
        if let (Some ctor) = maybePrototypeCtor then 
            ctor
        yield! otherArgs
    ]

with #1293

let fullArgs =
    [
        yield! ctor
        yield! otherArgs
    ]

[charlesroddie]

Duplicate of https://github.com/fsharp/fslang-suggestions/issues/705 : the goal is the same and the syntax is an addition to the many syntaxes proposed there. Don favoured match? there in https://github.com/fsharp/fslang-suggestions/issues/705#issuecomment-1157739765 .

The syntax proposed here is not good because the match syntax already exists and complete pattern matches are expected.

[xp44mm]

This paragraph speaks my heart, @TheJayMann

It sounds to me that the suggestion above could be generalized to allow match expressions in general to not require exhaustive pattern matching if the expression itself is typed unit,

F# allows omit input the last wildcard pattern | _ -> () in match expressions. Just like F# allows for omitting else () in if expressions.

[bartelink]

the huge difference between a wildcard ignore in a match and an implicit else is that there are exactly two cases is an if expression, and omitting the else clause stands out.

As Charles says, if the expression being matched on changes such that the cases are no longer totally covered, it's an important feature that the compiler tells you (it's rarely a good idea to turn off the warning and/or resolve it by adding a catch-all _ -> ())