while ... do: inconsistent handling of whitespace / indentation

[mathias-brandewinder]

while ... do expressions handle whitespace / indentation in a manner that is not consistent with if ... then ... else expressions.
This is problematic when the test expression is lengthy and would be more clearly written using multiple lines, along the lines of:

while
    x > 10
    &&
    x < 20
do ...   

Repro steps

Provide the steps required to reproduce the problem:

let mutable x = 0
while
    x < 10
do
    x <- x + 1

Expected behavior

I would expect this to be valid syntax, in a fashion similar to

if
    x < 10
then
    // do something
else
    // do something

Actual behavior

error FS0010: Incomplete structured construct at or before this point in expression
Missing 'do' in 'while' expression. Expected 'while <expr> do <expr>'.

Known workarounds

Any indentation of do resolves the issue:

let mutable x = 0
while 
    x < 10
 do
    x <- x + 1

[Martin521]

The current behavior is in line with the F# spec.
do is part of the while context and therefore needs to be indented like anything else. (The same is true for do in for contexts.)
For then/else/elif there is an explicit exception to the rule (see §15.1.9 of the F# spec) for good reasons (common case, avoiding multiple indentations).
But I wouldn't introduce any further complexity into the compiler for this case.

[Happypig375]

This is indeed a language suggestion. However, it is also in line with previous indentation relaxations -

• F# 4.5 permit undentation on [ ... ] and [| ... |]
• F# 4.7 Offside relaxations for construct and member definitions
• F# 6.0 Allow more undentations and remove inconsistencies
• approved in principle Undentation for string interpolation arguments fsharp/fslang-suggestions#1111
• Allow more undentation for tuples and dot-access (or give indentation warning instead of error) fsharp/fslang-suggestions#1433

[baronfel]

Definitely agree with @Happypig375 here - there are two 'expression' holes in a while ... do ... construction, and it feels very wrong for the 'holes' not to be able to be indented separately from the control-flow constructs. @mathias-brandewinder asked me about this yesterday, and I was actually stumped - having used this language for more than a decade - about why the behavior would be the way it is.

The main reason I can think of not to do this is syntactic ambiguity between do block in a while ... do ... vs a 'bare' do block - this I think the parser already is capable enough of handling that.

[Happypig375]

This might also be applicable to for ... = ... to ... do, for ... = ... downto ... do and for ... in ... do loops too.