Unity Future .NET Development Status

Idc, we are NOT talking about naming of general code but a single name that will be used by everyone in many places using Unity. Thus short it better. By inlining I meant that Task word is more common than Coroutine/Routine in NET world.

The point is to avoid conflicts with System.Threading.Tasks.Task, just like UniTask.

 

Ok, should be a bit quicker to type with intellisense than UnityTask. Slower than UTask

And a lot better than AwaitableCoroutine ofc.

 

Why not something a little shorter (and more common in other languages, as well), like Promise or Future?

 

UniTask would be ideal, but I guess that's not an option. :/

In .NET there's Task and ValueTask, so having a similar name would be good imo (just don't make it too long).

Dropping coroutine is the way to go - that name will forever refer to IEnumerator based methods. It would also lead to confusion in web searches.

 

Just commenting to give my support for that idea.For me it is perfect, it is generic enough for everything it handles while still being clear in its meaning.

 

Awaitable

doesn't indicate something that's providing Unity-specific methods or context in an Task-like way to me, but I like it way more than anything with Coroutine in it, so in the scheme of things it's fine.

Promise

,

Future

,

Eventual

, all make me feel like names from university computer science. I'm glad Microsoft decided to use Task instead, because it ends up making a lot more sense in context without making an abstract semantic bridge.

 

Honestly, I think

UnityTask

is best. For reasons others have already listed.

 

If it's another implementation of

Task

, then its name should be something similar to that.

 

It looks good and acceptable to me. However "Awaitable" is too abstract so I hope in the future it can be used for other things that might arise and we won't have to invent another type again.

 

ValueTask also doesn't have a Run() method.

Task itself simply means "work that can be waited for" .NET also uses Task for everything possible, whether threading, IO, web request. Task is already pretty abstract here.

 

I would also vote for something Task-like. Every scenario that has been showed to use is basically Task-like. The Awaitable name is too generic imo. Also keep in mind that neuecc with UniTask was clear - this whole thing is a unity specific task-like implementation. Since that name is already taken, just make it a little longer: UnityTask. Its usage is clear, it follows the same patterns used by Microsoft in the BCL and other libraries.

Also Unity really likes to add the U prefix to everything - Uxml, Uss, Upm, why not just name it UTask?

 

UnityAction
UnityEvent
UnityWebRequest*

There are at least 3 examples with the Unity prefix so as not to collide with .NET APIs. I don't see a problem in calling it UnityTask with the Unity prefix and making clear that they are exclusive APIs for the Unity domain. I also see that using the Task concept will make its use clearer and it will be better understood for people who already used the .NET Task class or the UniTask package.

 

Regarding the issue of receiving a callback when destroying an object: I understand that it would introduce overhead, but wouldn't that overhead only be relevant if you are destroying a huge amount of objects all at once? It seems like a highly specific scenario, to the point where I think at least supporting it as an optional feature would be worthwhile.

There are many approaches to making such a toggle "zero-cost", but I think it's worth pointing out an option for future versions of Unity once the .NET migration is complete. A "static readonly" of a primitive type can be treated as a runtime constant by the JIT with tiering, allowing you to have "feature flags" like this that won't have a performance impact if you disable them (I believe NativeAOT is also aware of how to transform many of these into constants.)

A particularly good example of this is in the Performance Improvements in .NET 7 blog post (Ctrl+F for "This is so useful that components are now written with tiering in mind." to reach the section I'm referring to.)

I suppose the engine could have two "Destroy" functions on the C++ side (one that invokes the callback and one that doesn't) and the managed implementation would call the appropriate one based on the feature flag.

I'm skeptical of the impact that a single branch would have in the Destroy method to begin with, but this would cover the scenarios of both users that want more functionality, and those that are unable to cope with any potential performance regression introduced by the branch.

 

My 2 cents: why not just "Awaitable"

My rationale is that these are things that can be awaited, they may be coroutines, they may be just waiting for the next frame, they may be resolved with a callback, etc...
If this is just like Task, they may or may not have a value
So they only thing they have in common is that they can be awaited.

To make it unity specific, just put it in a unity namespace. I suppose you could do smurf convention and call it UnityAwaitable but that would be redundant because your class will be in a unity namespace anyway.

.Net calls it Task and ValueTask for legacy reasons. They were available before async/await and were used for multithreading, they just decided to reuse them for asynchronous programming instead of writing a new class or struct with a better name.
Java calls it Future<>, which implies it will provide a result sometime in the future.
JS calls it Promise<>, meaning they promise to give a result some day.

All of those options are easier to type and easier to read than AwaitableCoroutine, which is a mouthful and does not really reflect what it is ( it may not be a coroutine at all).

Update: lol, I was late to the party, I see a post from the dev up there proposing UnityEngine.Awaitable

 

A

Task

is an abstraction over an asynchronous unit of work. The fact that your type will not have some threading options that the BCL type has does not mean it's not a task.

async UnityTask

is building a state-machine to do asynchronous work, so it is, by definition, a task. Just like

ValueTask

, like @runner78 mentioned. There is no need to complicate the naming over nit-picking about extra APIs.

 

Task was created by microsoft for multithreading. Later, when they added asynchronous API, they decided to reuse the Task class for the purpose.

So the name Task is there strictly for legacy reasons. Had Microsoft have asynchronous programming from the beginning, it would most likely have a very different name.

So "Task" is less than ideal. The only reason to use "Task" for this purpose is to appeal to people already familiar with Task from .net, not because it is the most descriptive name.

 

I don't think that's relevant for what a

Task

is and how it's used today. I think the

Task

name is very descriptive of what it is, and MS made the correct decision to keep using it. The fact that it helps get regular .Net people familiar with the system is a bonus to me, but I think it is also the best name itself.

 

This feels good to me!

 

I was also under the impression that

Task

was a specific kind of awaitable, and not the most abstract thing. Really all you need for something awaitable is a

GetAwaiter

method, and those are not always "tasks".

In this case

UnityEngine.Awaitable

has 2 main features it seems like?

1.

GetAwaiter()

2. Custom Unity-optimized async state machine implementation

If it's the same thing under the hood as a coroutine, but it just runs with a different interface,

Awaitable

makes sense to me (as the coroutine part is implied).

EDIT:

Really my main concern is that it communicates whether or not it's a suspending function on the main thread like coroutines, or if it's running on a separate thread. That's usually all I'm worried about when using async/await.

 

On the consumer side, you don't need to know if a

Task

is running on a separate thread or not. It is completely abstract. Tasks can run on the main thread just like coroutines, and often times do with

async Task

methods.

 

I think @jasonboukheir3 asked if using a UnityTask is a viable method of not stalling or lagging the UI ( as an example ).
Imagine this... Your Main Thread is running a complicated algorithm like a pathfinding one, and then you want the player to still be able to click on the GUI with it staying responsive. What do you do? Tasks is the answer as they are multithreaded!

This was a video by Unity themselves in 2019 where they used Tasks to wait for a button press in a popup from the user!

I think this video summarizes the differences between the 2 methods and is HIGHLY VALUABLE!

Alot of UI can be done using Tasks in a better way than having it all run on a single thread.

The year is 2022 and no CPU nowadays has less than 4 cores!

 

A task is just a "(still sub-divisible) unit of work", if it runs synchronously in the same thread, asynchronously in the same thread, in parallel in a single separate thread or in parallel as async continuations in a thread pool is completely independent of the task object/struct itself.

 

Wait does this mean Tasks aren't multi-threaded?

 

They can be used for both multithreaded, and asynchronous single threaded code.

 

Ahhh! Ok thank you for the clarification!
Always learned that they were only multithreaded…

 

Can we please get an update from the Unity Team, if you guys decided to name it UnityTask or are going to stick with the old name or choose a different name and why you can't just name it UnityTask...

You never really went into why it can't be named UnityTask and just presented other names...

 

they are not really tasks. They are things that yield execution until an event sometime in the future.
For example, if you wait for the next frame, there is no task going, it is simply yielding execute to something else until the next frame.

Here is another example that I do all the time with UniTask:

Code (CSharp):

1. public UniTask<Result> SomeApiAsync(Request request) {
2.     var tcs = new UniTaskCompletionSource<int>();
3.      SomeApi(request,  (result) => {
4.           tcs.tcs.TrySetResult(result);
5.      });
6.      return tcs.Task;
7. }

Some third-party APIs use callbacks to give results. But I find this really unreadable when I have to chain 3-4 calls. Callback hell is a real thing.

So I wrap the call behind a UniTask by creating a UniTaskCompletionSource. That way, I can call this function like this:

Code (CSharp):

1. public async UniTask MyCode()
2. {
3.     Result result1 = await SomeApiAsync(new {....});
4.     // now continue using the result,  possibly calling other async api.
5.     // no nested callback hell
6.  
7.     Result2 result2 = await OtherApiAsync(result.x)
8.  
9.     Result3 result3 = await YetAnotherApiAsync(result2.y);
10.    
11.  
12. }

Note that despite the name, there is no task going on at all. All the UniTask<int> really is syntax sugar for a callback.

The only reason this was called Task in the first place, is that Microsoft created the Task class for multithreading, but later on when adding asynchronous API, they simply reused the Task class. So the name Task is there simply for legacy reasons, not because Microsoft thought it was the best name for this.

Other languages call it Future or Promise, C# is the only one that calls it Task, just for legacy.

 

@goldbug You're too hung up on threads. Tasks are not just wrapping threads. Tasks have always just been fancy callbacks.

TaskCompletionSource

has existed as long as Tasks themselves, for the same purpose as your UniTask code.

Source? I think that's rather ridiculous, Task is a perfectly good name for it.

 

This thread has gotten wildly off topic. Can we make a new thread for debating the naming conventions of a new Unity feature, and keep this one for updates on .NET in Unity? Unless I'm misunderstanding something, these are largely separate topics.

 

^^^

 

@ProtoTerminator

Task was created in .Net 4.0. Basically, the only thing you did with them was put them in a ThreadPool. Which is why you find the Task class in the System.Threading package.
They represented a task to be executed in a thread pool, and thus they were named Task.

In computer science what we are talking about is called future or promise. The .Net developers did consider creating a Future class. As a matter of fact, the original Parallel Extensions CPT did use the word Future. However, Task was already there and it was rather nice to be able to reuse them for both asynchronous and multithreaded code.

 

I don't think it matters if its main purpose was for multithreading, if it is the name that was chosen by Microsoft for C# then it should be pretty self explanatory why Unity should also use that name. Especially when both are used similiarly.

Also when Unity ever decides to add multithreading ( which they should seriously do or at least consider ) then the naming can still work as Task is generic enough.

But that is not my point... My point is that Tasks where made to be awaitable and if Unity decide to copy that behaviour then the name should also be copied...

Also you yourself said it... They are both, multithreaded and singlethreaded code using asychrony!

 

Yielding itself is a task...

These terms aren't used in Unity or .NET devs. No reason to add more confusion.

 

Awaitable

is the way to go if you want to represent an abstract awaitable object. Given it's under

UnityEngine

namespace, the critique about it not being Unity-specific doesn't apply. Making it an interface would be even better, but I guess that's not an option due to struct boxing.

 

Yes, the correct decision by microsoft would have been to create a new construct for the language, probably called Future or Promise. But they did not, and as the years went by things that represent a unit of work and can be awaited became known as tasks in the .NET world. Right now (and in the foreseeable future) everybody understands that. You see some code with UniTask, you understand that. You see Task/ValueTask, TaskCompletition sources you understand that. Calling the same thing but in a Unity context Awaitable (or something similar, or even Futures) will confuse people. It will confuse people coming to Unity from other .NET frameworks, it will confuse people when they try to learn about asynchronous programming in .NET (because of the vast number of articles already written in the topic using tasks). It will only not confuse people intricately knowledgeable of unity callbacks and coroutines, and even they would understand UnityTask.

Imo UniTask would be better - but it is taken. UnityTask is the least path of resistance, and is the clearest solution to the problem. Before the Unity team mentioned awaitables and couroutines for the new names, nobody would have suggested using those names.

 

Agreeing with the people who say to call it "UnityTask." Something that looks like a Task and quacks like a Task and is designed to be used with the async/await pattern like a Task should be called some sort of Task. This is the standard the .NET team established when they came up with ValueTask. It's the standard that UniTask follows. To do otherwise would be a painful POLA violation.

 

Are you certain that this thing looks and quacks like a C# Task, though?

From everything I've read by @simon-ferquel-unity on the topic, the concept Unity is developing is more abstract than C# Task. See:

If you take the time to read the sample code that @simon-ferquel-unity cooked up for us you'll see that the API looks very different from the standard Task API.

Personally, with my current understanding of the topic, I agree with @goldbug:

Why doesn't Unity use one of those terms? My guess is baggage: that using such terms will create expectations (as would calling this some variant of UnityTask). By using something with perhaps less precedence in the field, they are free to define and implement it as they see fit without having to force people to unlearn knowledge from another domain.

I could very much be wrong about this - I am not [yet] a heavy user of async/await patterns in C# - but everything I've looked at to see why everyone keeps saying "Call it UnityTask! It's that breed of duck!" seems to say otherwise; that this is not the duck you are looking for.

 

It looks exactly the same. Awaitable.Run doesn't make sense as Task.Run is used to run on separate thread.

To be honest if that's the case I prefer UniTask over Awaitable as is has RunOnThreadPool() allowing to mix single and multithreaded code.

That whole example in UniTask (with bonus threaded task):

Code (CSharp):

1.  
2. public class NewBehaviourScript : MonoBehaviour
3. {
4.     // Start is called before the first frame update
5.     async UniTaskVoid Start()
6.     {
7.         // async operation, no cancellation
8.         await SceneManager.LoadSceneAsync("Foo");
9.         // DelayedCall usage
10.         await UniTask.NextFrame();
11.         // async operation, with cancellation
12.         await new UnityWebRequest("https://www.unity3d.com")
13.             .SendWebRequest()
14.             .WithCancellation(this.GetCancellationTokenOnDestroy());
15.         // start task in the background
16.         var downloadUpdateTask = UniTask.RunOnThreadPool(DownloadUpdate, true);
17.         // composition and UnityEvent
18.         var playerName = await PlayerNamePrompt.AskPlayerNameAsync(this.GetCancellationTokenOnDestroy());
19.         await downloadUpdateTask;
20.     }
21. }
22. public class PlayerNamePrompt
23. {
24.     public static async UniTask<string> AskPlayerNameAsync(CancellationToken t)
25.     {
26.         var prompt = new PlayerNamePrompt();
27.         prompt.ShowDialog();
28.        
29.         using var handler = prompt._okOrCancel.GetAsyncEventHandler(t);
30.         if(!await prompt._okOrCancel.OnInvokeAsync(t))
31.         {
32.             // user clicked cancel
33.             throw new OperationCanceledException();
34.         }
35.         return prompt.UserName;
36.     }
37.     UnityEvent<bool> _okOrCancel = new UnityEvent<bool>();
38. }
39.  

I'm surprised even UnityEvents work in UniTask. Didn't notice that before.

 

Yes, it's not a pre-TAP

Task

. But it's pretty rare these days for people to use that part of the

Task

API anyway; it's not much of an exaggeration to say that Task is synonymous these days with TAP and async/await. And with the proposed type being intended for use as an awaitable, it makes sense to call it a type of "Task".

 

Guess not, huh. Bummer.

 

The API does not look the same. The structure of the code may look very similar but that is more due to being usable in the async/await pattern than anything else.

 

But does it work the same? Yes it does!

 

Any news about that? Using source generators is a pain right now. Very slow iteration as all asmdefs reference all generators requiring full recompilation. Could we get some improvements for asmdefs if csprojs are far away on the roadmap?

Another issue is lack of errors/warnings from generators. When building usual csproj:

They are completely invisible in Unity 2021.3 console.

Tbh all planned features from this thread should be pulled out to separate pinned threads:
- .NET 6+
- async support
- csprojs and nuget
- keep this one for more ideas/requests

 

As I understand from what @simon-ferquel-unity said, Awaitable would be the foundation for other async APIs (like UniTask) to work better with Unity without having to invent new magic or piggyback on something unconventional. Could we call AssetBundle Addressables just because the former is the foundation of the later? Probably not. Then I imagine UniTask would be rewritten into vNext by chaging the foundation to Awaitable. (If you all remember, the team is working with @neuecc to design this Awaitable.)

 

Ahhhh! This now makes sense! If you are going to create an actual conversion to Tasks in the future then naming it Awaitable makes total sense now! ( Should've said it earlier )

This sounds amazing hope we can get our hands on this as early as possible, but please make sure it's implemented pretty well and not a rushed feature. TLDR make it polished!

Thanks for this news! This communication is really valuable!

 

I can't get incremental source generators to work in Unity even after replacing Unity's Roslyn with NET 6 version. They work correctly in csproj targeting netstandard2.1 and referencing the same dll.

Has anyone got them working? If not are there plans to make them work in Unity 2022 or 2023?

 

I was able to use .NET Community MVVM Toolkit 8.0 with its rewritten source generators in Unity 2022.2 with the built-in support that uses asset tags.