LDM Notes for April 1st, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-04-01.md

Agenda

• Async2

Note, I didn't ask Andy for the PDF of the presentation he gave until he was practically out the door on vacation, so I don't have it currently. It will hopefully be uploaded sometime next week; if I have forgotten to do this, please ping me! Presentation has been uploaded as well: https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-04-01-presentation.pdf.

[huoyaoyuan]

We like our current async syntax, and think that it should continue to be the main syntax for the future.

I'd also like to see discussion with F# team. The async syntax of F# is somehow less flexible than C# since ! is bounded by consumption statement rather than arbitrary expression.
The break for ref readonly with F# didn't feel good. Features with runtime impact should be discussed more proactively with F#. I don't want to see F# or VB to be left in the "legacy async" space.

Instead, the compiler can simply look for a RuntimeFeature flag, and turn on the new strategy if it's available.

This should be more limited by behavioral changes. Without a flag controlled by the user, they also lose a way to opt-in behavior changes as the default of new strategy.

Would you do some maintenance support for VB in this case? Can VB leverage the same code generation strategy with C#?

[vzarytovskii]

F#'s async has different implementation and will likely be not really relevant to the proposed changes, however we do generate a state machine for our task implementation. And this might require some changes.

[huoyaoyuan]

Glad to know F# is aware of this. I also wonder what's the mean for difference of async and task. Anyway, make F# leverage this as much as possible.

[DavidArno]

I am very disappointed with you, @333fred: notes for April Fool's day, and you post real meeting notes, rather than eg claiming the team were working on the new bsync keyword. 😁

[Richiban]

Honestly I thought they were doing something like that when the notes start talking about "async2", but then quickly realised that, no, these are real meeting notes.

They should have announced they were going to release a second version of C#, maintained side-by-side with the original, that is the same but with significant whitespace and without semicolons.

[333fred]

Honestly, April Fools didn't come up during the meeting once. Not once.

[MgSam]

nsync? And change await to bye bye bye?

[333fred]

Ok, that one's good. In a "ugh, no, aaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhhh" kinda way.

[vzarytovskii]

From the spec for async2:

As an initial restriction that is not fundamental, the tail. prefix is not permitted

Wanted to mention that tail prefix support is crucial for F#.

[colejohnson66]

Pinging for the PDF :)

[333fred]

Thanks for the reminder! It has been added: https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-04-01-presentation.pdf

[GabeSchaffer]

If we can get the runtime in cahoots with the compiler, does this bode well for getting yield foreach? It'd be great to get a solution to #378, allowing recursive iterators to work in non-quadratic time!

[CyrusNajmabadi]

No one has presented a solution for that that doesn't also come with unreasonable drawbacks for the common case of non nested iterators.

[GabeSchaffer]

If the runtime could do state machine generation for async2 that solves the sync-over-async problem, is it also possible that it could do state machine generation for iterators that solves the quadratic recursive iterator problem?

Of course it might not work for code that hadn't been recompiled or had manually implemented iteration, but async2 has similar limitations.

[CyrusNajmabadi]

, is it also possible that it could do state machine generation for iterators that solves the quadratic recursive iterator problem?

What would the solution be?

Even if you recompile, what it would recompile into that would solve th problem, without negatively impacting all other iterators?

[GabeSchaffer]

I don't have the answer, nor do I expect anybody else to have it. I'm just wondering if it's now on the table to re-evaluate the problem in light of this awesome new tool (JIT state machine generation) in the toolbox.