Wrong `when` expression parsing

[auduchinok]

The when expression in the following code is expected to be parsed as a sequence of ignore true and true, and the latter should be what the whole expression evaluates to.

match () with
| _ when
        ignore true
        true ->
    ()

The sequence expression is instead parsed as an application, ignore true true, and producing an error:

idea-sandbox\config\scratches\scratch_4.fsx(3,9):
  error FS0003: This value is not a function and cannot be applied.

AST Viewer

This is similar to #7741.

[TIHan]

Don't know if it's a bug yet or not. Will need to look at the design spec.

[auduchinok]

@TIHan F# 4.1 spec doesn't cover this particular case in the Lexical Filtering part. It looks like a SeqBlock is missing for when expressions and should be added, because currently such expressions are clearly not being parsed as the rest of expressions with the light syntax enabled.

[dsyme]

The expression after a when must be a declExpr which is a category of expression that excludes sequential expr1; expr2

patternGuard: 
  | WHEN declExpr 
     { Some $2 }

  | /* EMPTY */
     { None }

So this would be considered by design and needs to be clarified in the specification.

The workaround is to use (...)

match 1 with
| _ when
       (ignore true
        true) ->
    ()

[dsyme]

I'll close this as by design, I've noted above that a spec clarification is needed

[auduchinok]

The expression after a when must be a declExpr which is a category of expression that excludes sequential expr1; expr2

Could we allow at least the light-syntax implicit seqExpr here? Explicit ; would end an expression, as expected.
I find it very counter-intuitive when this error is shown on more real-life code samples. It also doesn't work good for beginners who are told that the language is indentation based and it doesn't work this way in this example.

[dsyme]

I'm not sure what the best approach is here

From a design perspective, it does feel right that the when should introduce an offside block, even if a declExpr is ultimately required.

But I suspect that making that change would lead to a fairly substantial breaking change - or at least it would be difficult to code to avoid that change. There are going to be plenty of pathological examples, likely occurring in the real world, as people do tend to use fairly messy formatting after the when

In balance I have not yet any real opinion on this beyond "if we can improve it without making a breaking change, then let's do that".

[auduchinok]

It seems that making more cases allowed than it's now is not a that bad change (please correct me if I'm wrong in this assumption), though, yes, I agree it may be difficult to code it this properly. I'd happy to try working on it, though, if there's now a chance it could be accepted!