Different indentation level changes behaviour of the code

[smoothdeveloper]

let foo t = "(" + t + ")"

let tttt =
  let text =
    match Some "" with
    | Some t ->
      match t with
      | "" ->
        "a"
      | "b" ->
        "b"
      |> foo
    | _ -> "fooo"
  text  

let tttt' =
    let text =
        match Some "" with
        | Some t ->
            match t with
            | "" ->
                "a"
            | "b" ->
                "b"
            |> foo
        | _ -> "fooo"
    text

In foo I use two spaces for indentation, in foo' four spaces are used.

The resulting expressions are different while I'd had expected those to be the same.

I tried to find something which would explain that in the language specification (which I haven't thoroughly read) but failed, and the behaviour seems to fail me at "principle of least surprise" so submitting this as an issue to get clarification.

Thanks.

[radekm]

IMO it seems correct - see the specification 15.1.9 Exceptions to the Offside Rules - the first exception:

An infix token may be offside by the size of the token plus one.

Here is a similar example:

let (||>) = (|>)

let () =
    let x =
        match "" with
        | "" -> 1
        | _ ->
            4
        |> (+) 9
    printfn "%A" x

The code prints 10 because the exception doesn't apply (the expression in the second branch of match is 4).

But if you replace |> by ||> or decrease the indentation of the line with 4 by one space the result will change to 1 because the exception to the offside rule will apply (the expression in the second branch of match will be 4 |> (+) 9).

[smoothdeveloper]

@radekm, thanks for bringing the relevant spec bits.

This seems like a serious gotcha to (try to) keep in mind while writing F# code.

[dsyme]

@smoothdeveloper Please consider opening a suggestion on http://fslang.uservoice.com to request a warning for the first of these cases. It would be great if you could formulate an exact proposed rule (e.g. one that would cover the interaction with "match", but no more, unless you identify other similar interactions).

[smoothdeveloper]

@dsyme you are right, a warning might make the most sense, but I'm trying to wrap my head around all the cases shown in the spec.

Wouldn't it be simpler/better to have a strict-indent compiler flag which disable the subset of those rules related to expressions (don't want to impact the type related and for constructs)?

Reasoning for restricting to the expression related exceptions is that unlike other cases, they tend to not lead to compiler error and generate code the user didn't intend.

[dsyme]

@smoothdeveloper We try really, really hard not to add compiler flags that "fork" the language (or even restrict it). It's possible that adding the warning to FSharpLint or Fantomas or FSharp.Compiler.Service may be the right place.

[smoothdeveloper]

Reopening in case this can be a warning: we should always recommend putting the thing to be piped between parens (for this very particular case at least), this still behaves the same.

Related suggestion: fsharp/fslang-suggestions#806

[brianrourkeboll]

@smoothdeveloper It would be relatively straightforward—at least as an analyzer, if not during type checking—to emit a diagnostic when a SynMatchClause ended in a SynExpr.App of an infix operator (or specifically a pipe operator), the operator's right-hand argument was not on the same line as the left-hand argument, and the start position of the operator was leftward of the left-hand argument (or was on the same column as the match clause's |, as in your example).