Unity Future .NET Development Status

Does that include a moving/generational GC?

 

Unity 2021.2 has support for all of C# 9. From reading this topic, it seems like 2022.1 has everything in C# 10 but may have bugs surrounding DIMs.

Now if only Unity could serialize records...

 

Alright boys, time to take the week off to celebrate

@JoshPeterson does this affect the work done here by any chance?

 

Small bump: .NET 6 has been released.

 

.NET 6 has been out a few days now and I'm loving it, along with C#10's new features and the snappy new VS2022, what's the latest updates on unity adopting these new changes @JoshPeterson ?

 

Page 9, bottom posts in this thread -- you will find the answer

 

Holy cow this is fantastic, and so, so much faster than I imagined when you started this thread a few months ago. Y'all have been absolutely killing it with not only progress but the communication the whole way.

So now I gotta ask the "magical christmas land" question: the fact that this is getting work now, does that mean there's a nonzero chance this slips in before 2021 LTS?

 

Any ETA for Unity .NET 6 preview?

 

It have been said that 2021 won't ship any new feature.
I'd be happy if it manages to land in 2022.2

 

It's likely too early to answer, but just in case: what are the chances of .NET 6 support being accompanied by the modern csproj format?

 

I figured as much, but still had to ask. Appreciate the info

 

Hello, I have a project with my team using Colllab. We are using Unity 2021.1 and Net.4.x . When we download the project to a new computer, to Unity 2021.2 it breaks the project. After many tests we noticed that Net 4.x is not in Unity 2021.2 and believe this is what is causing the project to lose all of the scripts. If this is the issue is a way to fix it?

 

https://docs.unity3d.com/2021.2/Documentation/Manual/dotnetProfileSupport.html

 

Thanks for the update. IMO, a modern JIT* is the single greatest performance improvement that Unity could do right now. It's not as flashy as DOTS/ECS or Unreal Nanite or something like that; it's nothing you can use to impress investors or brag about at GDC. But, it's the foundation upon which all non-Burstified user scripts, asset store packages, custom editor extensions, and an increasing number of Unity-internal packages are built.

So... thank you Josh and the rest of the scripting team!

* (Not that Mono is bad, but there are things that can be accomplished with the several billions of dollars which Microsoft put into their JIT)

 

Now that the editor / engine itself is compiled against .NET Standard 2.1, i also hope that Unity will use this as an opportunity to use some modern APIs such as Span<T>, with the help of which the .NET core standard library already brought a much higher performance.

 

i'm writing a high performance network API with .net standard 2.1, libraries like Memory, Span, Array... are working as expected in the new Unity with standard 2.1, i'm happy.

 

Yep, I wonder if UnityWebRequest could be rewritten purely in C# and work on all platforms give how bad its performance is at the moment.

 

Could you add an implicit conversion from

Span<T> where T : unmanaged

to

NativeArray<T>

(with some special allocator label)? That would require bookkeeping at the GC level if you scheduled a job with one, but it would make integrating into existing Burst/jobified APIs much easier.

 

I am not sure if that would be possible, or doable. Span<T> support both unmanaged and managed references (for example, a span can be backed by an array). So the GC must be aware of this reference. AFAIK NativeArray<T> are not GC-aware, so it wouldn't work (also taking into account that Unity uses an old GC + the engine itself is unmanaged [i.e: not aware of managed references] it will also decrease the chances of working). Remember that Span<T> is a ref struct, while NativeArray<T> is just a struct.

However, the opposite, i.e: NativeArray<T> -> Span<T> would be possible (though it would lack the Dispose method).

Alternatively, it may be possible to implement Memory<T> -> NativeArray<T> since the memory holder is known (it's a field inside the Memory<T> instance, not like in the Span<T> where the origin pointer may or may not be an offset into a managed array). However, that would require the native array to also store a managed reference (pinning the object with a GCHandle?) and an offset field for those cases.

Also, the conversion NativeArray<T> -> Memory<T> would be possible... though it would require the allocation of a custom MemoryManager<T> that would back the Memory<T> instance by holding the pointer and length of the NativeArray<T>.

Please correct me if my assumptions are wrong. I would also like that conversion between Span<T> and NativeArray<T> XD.

 

Just note

Currently unity use non Moving GC so once allocated array is not moved and according to this unity dont have plans to move to Moving GC.

So if you can guarantee that array have root from managed side that you can send pointer to it into native side freely

Thus if you have some array of data inside MonoBehaviour you can array → span → native array → send to job or process with bursted method.

 

It's true that with a non-moving GC it's much easier (yet somewhat difficult) to implement this. However, in that post they said that don't plan to change the GC initially. So there is a chance of doing this in the future (probably after moving Unity to .NET 6 successfully they may reconsider it). So adding a feature that would likely block forever that future change is not a good idea IMAO.

 

Yes, it would require a bit of extra bookkeeping on the GC side. However this already works, as long as you're prepared to keep track of the underlying reference (or GCHandle) yourself:

Code (CSharp):

1. public static unsafe NativeArray<T> toNativeArray<T>(T* ptr, int length) where T : unmanaged
2. {
3.     NativeArray<T> arr = NativeArrayUnsafeUtility.ConvertExistingDataToNativeArray<T>(ptr, length, Allocator.Invalid);
4.     #if ENABLE_UNITY_COLLECTIONS_CHECKS
5.         NativeArrayUnsafeUtility.SetAtomicSafetyHandle(ref arr, AtomicSafetyHandle.GetTempUnsafePtrSliceHandle());
6.     #endif
7.     return arr;
8. }
9.  
10. public static unsafe NativeArray<T> toNativeArray<T>(Span<T> span) where T : unmanaged
11. {
12.     // assumes the GC is non-moving
13.     fixed(T* ptr = span)
14.         return toNativeArray(ptr, span.Length);
15. }
16.  
17. public static unsafe NativeArray<T> toNativeArray<T>(ReadOnlySpan<T> span) where T : unmanaged
18. {
19.     // assumes the GC is non-moving
20.     fixed(T* ptr = span)
21.         return toNativeArray(ptr, span.Length);
22. }

(and also you can't schedule a job with it, but that can be gotten around by passing the pointer/length).

Fair enough.

 

I may be wrong but you are not pinning the pointer. The current GC is non-moving so references won't move (this doesn't mean in the future it may). Yet, you still need to pin the reference, otherwise, it may get garbage-collected and the pointer would become dangling. But the real problem is that Span<T> can contain either of these 3 things AFAIK:
1) An unmanaged pointer: which doesn't require pinning.
2) A managed pointer to an array/string: which requires GC-aware or pinning.
3) A managed pointer to the interior of an array/string: which requires GC-aware or pinning to the actual whole array (not just the interior pointer, i.e: it must be able to figure out the object where this interior pointer came from).
And there is no API to check which of the 3 modes is actually being used, nor to pin an interior pointer (Span<T> works because they are a ref-struct, which means they can only exist in the stack and the GC is smart enough to figure the actual object in order to track it, but for performance reasons, this doesn't work in heap-allocated elements).

 

Yup. It's very clearly unsafe. It works as long as the GC is non-moving and you keep the reference alive somewhere else. I've only ever used something like that when I was trying to avoid copies when scheduling jobs, and had a reference to the underlying array that was kept until the job ended.

The 3rd problem could be gotten around because when you create the NativeArray, the Span is on the stack and has its ByReference<T> filled. I don't see the lack of a public API to be a problem; the JIT knows the reference and this is the team that's integrating the JIT. (EDIT: although a span can point to stackalloced memory also)

However, it would need the cooperation from the jobs/native array team to add support for managed references to NativeArray (via a special AllocatorLabel or something like that). That seems to be something that Unity doesn't want to do. Which is fair; it's a big ask.

 

I'd like to be able to use IAsyncEnumerable<T> and am a little confused which version of Unity supports this these days? Any guidance would be appreciated. Thanks!

 

Its part of Standard 2.1, also it should wok since Unity 2021.2

 

Thank you. That's exactly what I was looking for. I was also confusing .NET Standard with .NET Framework which wasn't making it any clearer. (4 > 2 right?!?)

Once 2021.2 is installed, it's more obvious as they have removed .NET 4.x . Although I still argue .NET Framework and .NET Standard should have names that are more distinct and clear. But then again this comes from a company that chose to name their console Xbox One, Xbox, Xbox Series X, Xbox 360 and Xbox Series S. I'm assuming X is an unknown variable?

This thread is good for the .NET Standard vs. .NET Framework confusion
https://forum.unity.com/threads/net-standard-2-0-2-1-vs-net-4-x-what-is-newer-better.1158806/

 

well, fortunately naming has improved immensely now. .Net 5 .Net 6 ......

 

Counting isn't exactly Microsoft's strong suit... 3.1, 95, 98, 2000, XP, Vista, 7, 8, 8.1, 8.1 Update 1, 10, 11

 

@JoshPeterson How is the resolution of this bug going?

https://issuetracker.unity3d.com/is...ing-package-when-building-on-android-platform

It's been active for a month and it's not fixed yet.

It is blocking us from publishing on Android and it is quite serious.

 

It'll most likely be fixed by 2021.3

 

Based on what?

 

@JoshPeterson One of C#8's most powerful additions is nullable reference types. However, use of this language feature is still a bit rocky as of Unity 2021.2:

• There's no easy way to enable nullable reference types for asmdef projects. Nullable reference types are typically enabled with the MSBuild

  Nullable

  property, which is not available for asmdefs. We can set the

  -nullable

  compiler flag in the Project Settings, but this creates a bunch of nullability warnings in all 3rd party scripts too. It would be great if the asmdef inspector included a "Nullable reference types" checkbox, similar to the other language feature checkboxes like "Allow 'unsafe' code". Currently, the best workaround seems to be adding

  #nullable enable

  to the top of every file using nullable reference types...
• The Unity APIs have not yet been tagged with attributes for null-state static analysis. This means, for example, that the compiler can't tell that a value is non-null even after calling

  Assert.IsNotNull

  .

Is your team already aware of and/or working on these issues?

 

You can add -nullable to a csc.rsp file

 

@steego Awesome suggestion! I was going to say that .rsp files apply globally and would have the same issues as adding compiler flags to Project Settings (showing warnings for all 3rd party scripts too), but then I found this other forum thread (that you had commented on lol) explaining how .rsp files can apply to individual .asmdef files. I also didn't realize .rsp files were for anything but #define symbols. It would be nice if this were more hierarchical so we didn't literally need one .rsp per .asmdef, but this is probably the cleanest solution available right now.

Note that my comment about decorating Unity APIs with nullability attributes still stands though.

 

Is it expected to use records with positional parameters in 2021.2?

Code (CSharp):

1. public record Node(uint counter)

in 2021.2.4f1 it fails at compilation with

 error CS0518: Predefined type 'System.Runtime.CompilerServices.IsExternalInit' is not defined or imported

 

Unity 2021.2 does not have full support of C#9.

to use records you need to define

System.Runtime.CompilerServices.IsExternalInit

by yourself

Code (CSharp):

1. namespace System.Runtime.CompilerServices
2. {
3.     public /* or internal */ static class IsExternalInit
4.     {}
5. }