allow begin end on one line in safe cases

[EmileTrotignon]

you get

begin f x end

The only "unsafe" case is

f begin fun () -> x end

which has a hovbox and is difficult to get without allowing the following:

f begin fun () ->
  x ;
  y end

Because of this

f begin fun () -> 
  x 
end

is forced

[Julow]

Do you have examples where begin .. end on a single line is better than parentheses ?

I'd find it more useful if OCamlformat removed begin .. end that fit on a single line. For example, if you modify a large expression inside a begin .. end until it becomes small, you end up with code like this (on main):

  g ~y:begin
      f x
    end

If you allow this to fit on a single line, you get (with this PR):

  g ~y:begin f x end

which is a lot harder to read than it could be:

  g ~y:(f x)

[EmileTrotignon]

I agree that parens is usually better, but removing beginend automatically can get annoying if you were in the process of modifying.

I also worked quite a bit on a automatic begin-end bracketing feature, which was more ambitious than this (it also added begin end instead of multiline parens) and it was more complicated than you would think.

The last issue I had is that formatting would not converge because in some cases, begin x end would be formatted on one line, but ( x ) would be formatted on multiple.

Of course, since the transformation is only one way here it would converge, but in some (rare) case you would get parens on different lines instead of your begin end clause.

Also, something I should have mentionned is that a big motivation of this is all the begin end shortcut syntax I introduced.

begin
  fun x -> y
end

became

begin fun x -> y
end

which begs to be on a single line (or to have parens)

[Julow]

The complexity came exclusively from turning parens into begin..end. Removing begin..end is very easy: https://github.com/ocaml-ppx/ocamlformat/blob/main/lib/Extended_ast.ml#L282
I think it's possible to come up with a heuristic that avoids identified cases where parentheses use more lines than begin..end.

I totally agree that this could be annoying while editing. Perhaps we could make the heuristic more complex to avoid some of these cases ? For example, don't remove begin..end on a match case if an other case has them, don't remove them in begin fun, etc..

[EmileTrotignon]

This looks a bit more complicated than I intended, I think this is okay to merge as-is, its always possible to remove the begin-end by hand. I would be okay with more functionnality in a later PR