Allow implicit calls with inline for/while?

[helixbass]

Noticed this while working on the Prettier plugin: there's currently an asymmetry between inline if vs inline for/while with respect to implicit calls

Eg this parses:

a if b then c
a b, if c then d

While these don't:

a while b then c
a b, while c then d

a for b in c then d
a b, for c in d then e

I started playing with this on my allow-implicit-call-for-while branch but was running into some tricky stuff in the rewriter

So opening this issue at least as a reminder

Not sure if there's ever been any consideration/discussion of this?

[Inve1951]

IIRC you need parens.

a (while b then c)
# or
a (c while b)

Without them it's hard to tell the expected behavior even.

[helixbass]

@Inve1951 yup for the postfix case you'll always need parens eg

a (c while b)

For the non-postfix case you're right that currently you need parens eg

a (while b then c)

This issue is about whether we want to support not needing parens there

I agree that it wouldn't often be a great choice to omit parens since it starts to read similarly to a postfix eg

a while b then c

vs eg

a while b + c

But I don't think there's any actual ambiguity because of the then

And you could argue it's not really visually confusing if it's not the first call arg, eg

a some(firstArgument), for b in c then b(x)

It's an edge case usage-wise since I don't think a lot of people write inline non-postfix while/for, especially as call arguments

But it's supported for if so typically it's unexpected for there to be an asymmetry there

And for me it came up not because of practical usage but rather because in the Prettier formatter I need to set rules around whether call parens can be omitted and so currently I need to handle while/for differently from if