New async extensions

[dnikolovv]

A list of the added extensions.

Task<Option<T, TException>> SomeNotNullAsync<T, TException>(this Task<T> task, TException exception);

Task<Option<T, TException>> SomeWhenAsync<T, TException>(this Task<T> valueTask, Func<T, bool> predicate, Func<T, TException> exceptionFactory);

Task<Option<T, TException>> SomeWhenAsync<T, TException>(this Task<T> task, Func<T, bool> predicate, TException exception);

Task<Option<T, TException>> ToAsync<T, TException>(this Option<T, TException> option);

Task<Option<T>> ToAsync<T>(this Option<T> option);

Task<Option<TResult, TException>> FlatMapAsync<T, TException, TResult>(this Option<T> option, Func<T, Task<Option<TResult, TException>>> mapping, TException exception);

Task<Option<T, TException>> FilterAsync<T, TException>(this Task<Option<T>> optionTask, Func<T, Task<bool>> predicate, TException exception);

Task<Option<T>> SomeNotNullAsync<T>(this Task<T> task);

The tests aren't very exhaustive, but that's what I can do at the moment.

Let me know your thoughts.

[silkfire]

@nlkl @dnikolovv What's the status on this feature request? I read that the async extensions would be part of release v5.0.0, but last I checked that one still seems to be in alpha stage.

[dnikolovv]

@silkfire

That's the nature of open source.

I've been using my own Optional.Async library for quite a while now. It's not extensively maintained but it gets the job done.

[silkfire]

@dnikolov

No worries. I decided that I could make some useful improvements to the library and in result rolled my own fork: https://github.com/silkfire/Ultimately

It includes the async extensions by default.

[nlkl]

Hi,

Regarding async support in general, I’m afraid I don’t have as much time anymore as I used to, which is why this is progressing very slowly.

In general, the implementation is ready and the released alpha version seems to work as expected - however, it needs a lot of work on the test suite before I can mark it as stable.

I do hope the community will step up and help implement the test suite itself - I fully know this is not the most interesting thing to work ob, but it is nonetheless important if we are to ensure a high quality library.

Before I consider extending the async support further, we need to stabilize the operators that are already implemented.

Hopefully I will get more time in the near future, in which case I will stabilize things myself - but in the meanwhile anyone is welcome to help out implementing the test suite if they need async support stabilized here and now (and are of course welcome to also use the alpha version).

Thanks for the understanding!

Br,
Nils

[RaringCoder]

@nlkl @dnikolovv I'm happy to step up and help. Are there Issues representing the work that needs doing?

[PatrickVdWillik]

@nlkl I'm a big fan of using Optional and really miss native async support. You said you'd like the community to step up and help finish the test suite. Can you give a (short) synopsis of what needs to be done there so others can help?

[nlkl]

Hi @RaringCoder and @PatrickVdWillik

Sorry for missing your offers to help. Awesome to see someone volunteering to help out, so I feel a bit ashamed for getting back to you this late.

In general, the test suite for the new async extensions need to match that of the non-async versions. In addition, but not as urgently, it would be nice to also test that the "continueOnCapturedContext" flag works as expected - even though that of course will be more tricky.

The original test suite was written many years ago and hasn't aged too well, so my thought was to make the test suite of the async extensions a bit more readable, and then later improve the existing tests.

/ Nils

[martin-hirsch]

I have the feeling this won't happen anytime soon?

[nlkl]

To be honest, I didn't expect much interest now that C# support nullable reference types - but I could probably release the current prerelease version fairly easily if there is an appetite (and it has, after all, been available and used for a few years without any issues reported).

The project could use a bit of love to bring it up to modern standards, though.

[martin-hirsch]

There's definitely still interest in this! NRT and your lib aren't really solving the same problem. NRT is essentially a lint tool. It warns you, but still let's you ignore null. Optional enforces handling null and enables functional composition (.Map, .Bind, .Filter) that NRT simply can't offer. For anyone leaning into a more functional style, your library remains the more elegant solution. A stable release would be very welcome!