nlkl / Optional

A robust option type for C#
MIT License
903 stars 73 forks source link

Match for async lambda doesn't return awaiter and isn't awaited #73

Open jmrnilsson opened 4 years ago

jmrnilsson commented 4 years ago

First and foremost: Thanks an absolutely awesome library. I still prefer this to new and improved null-handling as of today.

Case in point. I'm sending an async lamdba into .Match() and the only way to awaiter is to assign the task to a canonical value outside the lamdba scope.

Below statement will just fire-and-forget.

                            messages.Match
                            (
                                some: async msgs =>
                                {
                                    var lastReferenceId = await messageRepository.AddRange(msgs);
                                    lastReferenceId.MatchSome(referenceId => FasterOps.Instance.Value.TruncateUntil(referenceId));
                                    logger.LogInformation("Flushed records");
                                },
                                none: () => delayCoefficient = 10
                            );
acg9 commented 4 years ago

This is related to #3 .

I really like this library and use it extensively but the lack of async support is really bumming me out.

There's a 5.0.0 alpha out there that I believe contains an alpha version of async support (what's currently in master). Unfortunately it was last updated around a year ago and I do not know how stable it is.

@nlkl Do you have plans to push 5.0.0 out? I use this library a lot in a Microsoft internal product, are you interested in help maintaining this library?

silkfire commented 4 years ago

@Iscgx Feel free to try out my fork called Ultimately. It has full async support as well as many other useful extension methods. Let me know if you need any help on the way, I haven't had as much time as I wish to put into the documentation :)

nlkl commented 4 years ago

Hi @Iscgx

As for the alpha version, it should be stable in the sense that the API itself isn't likely to change and in the sense that there hasn't been any issues reported since it was released. Apart from missing xml docs it should also be feature complete, so using it at this point should be quite safe in general.

However, what is currently lagging is really the test suite (adding xml docs should is mostly a matter of copy/paste), so the perceived stability is of course only based on anecdotal evidence. Any help on the test suite is definitely welcome, as I haven't had the time recently that the project really deserves.

The develop branch has also been updated to support nullable reference types, so there are few other things that will come out with version 5 too.

So in summary, v5 isn't actually far away implementation wise, but unfortunately it has been like this for way too long, which I'm obviously sorry about and hope to remedy in the near future - and any help on the test suite would be greatly appreciated.

/ Nils