Jérémie Chassaing

So, after more test, it found that is was truly linked to the size of methods due to F# inlining. Two keypoints: * The code emitted by F# in debug...

The latest version (2.2.206) version of MSBuild.StructuredLogger fails with a ArgumentNullException. It seems it's due to localized string not being initialized. This can be fixed by adding the following line...

sure, for now it can bind on ValueTask, Task, Async and awaitables. (I put Task in medium priority with Async to avoid resolution problems with `failwith`)

btw, who is in charge of writing the RFC ?

I don't know what triggers this error of duplicate `compensation@17` .. Seems related to the code generation in `.TryFinally`, but I can't see why it's failing only in specific builds...

I tried to make as few changes as possible compared to TaskBuilder: * I renamed types in the file to add a Value prefix * used `AsyncValueTaskMethodBuilder` from the Bcl...

Actually, ValueTask is available only in netstandard2.1, and is used more and more in recent frameworks. Having it OOTB in F# seemed sensisble.

Yes I understand. But at some point some new features will appear only in net6. 0+... Having them in Fsharp.Core will have to follow.

Yes that could be a nice way to do it. Still, since the type `ValueTask

From a DDD system point of view, the fact that the event was actually emitted by an aggregate is an implementation detail. You can spot this from the fact that...