What is UniTaskVoid?

[Razenpok]

So why do we need UniTaskVoid? After reading README and googling I still cannot understand its purpose.
It seems like it is a UniRx replacement for async void but you still need to .Forget() it - you can do the same with UniTask. Apart from that, you can't use it for Unity events like Start.
Also, I'm using async void Start in conjuction with UniRx, are there any downsides of it?

[canadaduane]

I also came to UniTask looking for this and would like to understand better what UniTaskVoid is for. In my case, I am looking for a way to use async/await in conjunction with the UnityEvent system, and since a Task return type is not allowed for the signature of a UnityEvent invocation, I'm wondering if this has been solved by UniTaskVoid?

[neuecc]

Functionally the same.
In the case of UniTaskVoid, there is no need to wait

• A little lighter because there is no need for a temporary object to return with await
• When an exception occurs, pass the exception to UniTaskScheduler immediately (In the case of normal UniTask, it is delayed until GC)

There is a difference.

[Razenpok]

So, what's the right way to do async void Start or something like that?

[neuecc]

unfortunately async void is system reserved so can not replace.
for eventhandling

FooEvent += () => UniTask.Void(async () => { /* */ })

otherwise use Forget().

[Razenpok]

I mean, is this a right way to use UniTask in Unity events?

private async void Start()
{
    await UniTask.Delay(1000);
    Debug.Log("Awaited");
}

And if it's not, what is?

[OJuergen]

TL;DR
I think you can use private async void Start(), but calling a function that returns UniTaskVoid is better practice.

Disclaimer:
not an expert, take with a grain of salt.

In principal async void Start() works. The task is scheduled and executed by the Unity main game loop. The main concern here is exception handling. Consider

private async void Start()
{
    await UniTask.Delay(1000);
    throw new Exception();
}

and compare with

private void Start()
{
    OnStart();
}

private async UniTaskVoid OnStart()
{
    await UniTask.Delay(1000);
    throw new Exception();
}

In the first case, the exception bubbles up to the Unity game loop where it is caught and logged and sent to UnityAnalytics. In the second case, it is caught by the UniTask library and logged by UniTaskScheduler where you can also configure the log level for this (warning by default). If OnStart() would return UniTask, the exception would only be logged with the next garbage collection, which happens at some undefined time in the future. Could also call Forget() on it or wrap it in UniTask.Void to prevent this.

Unity is special, because of the main game loop where all exceptions are caught. But in general, it is good practice to avoid async void, because when you kick off a task and don't await it and it throws, the exception can get lost. And even if you were to wrap the starting of the task in a try/catch, the exception would 'sneak out' and crash your app. You want to make sure you know what happens with any exceptions that are thrown. I think with UniTask exceptions don't get lost, because the tasks are executed via the Unity game loop. So async void is maybe not quite as dangerous.
Since Unity has no async/await built in, we cannot avoid async void completely, anyway. With UniTaskVoid and UniTask.Void, the place where the async void actually happens is within the library code and handled there. I think it is good to avoid async void in your own code as good as you can and use UniTaskVoid instead.

[Razenpok]

Thank you so much for this explanation @OJuergen, very cool.

I knew that async void has some pretty big downsides to it and should be generally avoided, but I guess UniRx.Async is an edge case to this rule. I'll dig into source code a bit more to figure out if there are any critical flaws to it, and if there aren't any, our team will continue to stick to this approach. I think exceptions being caught by Unity game loop is the right way of handling unhandled exceptions, since it's the default behavior for exceptions which are thrown by synchronous code.

Regarding Start forwarding: I think using UniTask.Void or Forget() is better because otherwise you get IDE warning when using non-awaited UniTaskVoid, while the former approach is a perfectly valid code.

[BurovAlexProgrammer]

Regarding Start forwarding: I think using UniTask.Void or Forget() is better because otherwise you get IDE warning when using non-awaited UniTaskVoid, while the former approach is a perfectly valid code.

I found some another "solution" to avoid warnings

private void Start() 
{
   _ = SomeUnitaskVoid();
}