Who are we helping with this open-paren check? I'd suggest doing away with it I guess it's fine to be more specific (only break the minimum we need) #Closed

i'm follow the grammar here. There's nothing wrong with having with on its own here. :)

I don't like this, but, I think it's consistent to have a with lacking parens here, being treated as a normal identifier.

Just waiting for Jared to write the blog post about the meaning of [with(with), with].

I compared with an attribute [assembly] lacking :, as the closest analogy that entered my head, which is allowed. .NET Lab.

Sorry. I misread. I thought you were asking me to change this. .

PROTOTYPE

?

We'll want to all-in-one syntax resource. We can either:

1. add it now
2. mark as PROTOTYPE to add it before merging to main
3. leave with follow-up link

There are two problems with option 3:

1. the linked issue was specific to one kind of syntax. I've updated its title now, since it looks like it tracks more syntax kinds
2. I'd prefer we avoid digging the hole deeper, as that means it's less and less likely that we fix it and essentially we give up on all-in-one in practice

Have done this in #80555. Whichever goes in first, i will fix the other.

have done this in #80555

It would be good if we can make a LangVersion error work in binding, if we can't bind with in [with()], to hint that maybe you meant to update your language version instead. There may be a similar error for record Rec() { ... } in language versions where record is treated as a method return type, or some similar case like that.

Sure. we can add that to the upcoming semantic work :)

... only now realizing why with was already a contextual keyword.

Perhaps [a.with()] is also worth testing as well as [(with)()]

Sure. Can i add in #80495?

Sure. Can i do in #80495

Yes

62aceeb

Ah, the diagnostics are the same with both parses. Neat

nit: it looks like this test could be condensed to use 'CollectionARgumentsOrInvocation' helper. Possibly i am missing something?

f2c6c4d

I'm inclined to think of the leading with as like the leading .. for spread elements, which leads me to wonder if we have a parsing test for something like [.. ..x].
This is not an actionable comment for this PR, just a thought that crossed my mind.

yes we do. TestSpreadOfRange1 and TestSpreadOfRange2

Is this expected? I thought that with a prefix await, that this would parse as an invocation always.

in this case, because we're not in an async block, the await is itself an expression (not the start of an async-expression). so this is parsed as [await , with()] (just with a missing comma). See the next test for an async context.

Ah.