Unity C# 8 support

Simple question is: Do Unity have plans to support C# 8. If they Do - When?

 

I doubt C# 8 itself has a release date yet.

 

Ok it is good thanks

Really I have just looking for undated roslyn compiler with support of C#8 so we can enable C#8 through csc.rsp and have benefits of NullableReference warnings in our project

 

You can play with the project I uploaded a while ago: Would the Roslyn Compiler compile C# 8.0 preview?

It has Roslyn C# 8.0 Preview compiler integrated. If there is a version of Roslyn newer than 2.11.0.63519, I believe, you can just replace the whole Roslyn folder there with the new version.

 

Thanks @alexzzzz I will try it

 

Any update on the release date for C# 8 support?

 

Update: C# 8 is released now, i personally need native json support
https://github.com/dotnet/corefx/issues/33115

https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/

 

Cool.
Waiting for Nullables support
I have event prepare command to make nullables warnings to be errors

 

How's it looking with C# 8 in Unity, any chance it will come with 2019.3?

 

May be you have plans to update C# compiler to latest released so we can adlast turn on some syntactic sugar without true support of new features?

 

+1 on this, since after c#8, default interface methods are supported.
https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/default-interface-methods-versions

 

+1, static extensions and default interface implementations are sweet ^_^

 

+1
I don't think static extensions are part of C# 8.
But I'm waiting for default interface implementation and some minor things like readonly members and unmanaged constructed types might fit very well into DOTS.

 

+5 million
simple 'using' statements
switch expressions

And a personal favorite;
this:

Code (CSharp):

1. int[] array = { 1, 3, 5, 7, 9 };
2. int i = array[^1]; // returns 9
3. int[] subArray = array[1..3]; // returns { 3, 5 }
4. int[] subArray2 = array[^2..]; // returns { 7, 9 }

 

array[1..3] should return 2 elements.

 

More than c# 8 I need .net standard 2.1 support (fast span). is there a plan for that or will they potentially come together?

 

Fast span is pretty important for working with memory in cache friendly ways.

 

I hope you guys can figure out a way for us to be able to just drop a new Roslyn whenever it comes out.
With the old incremental compiler, we could just replace everything (except csc.exe) and it would work with the latest Roslyn from nuget. So, we could update the compiler with a simple nuget.exe install Microsoft.Net.Compilers

Thanks for keeping us posted!

 

I personally understand the 2.1 limitation, however having C# 8 support will be quite great as it will improve quality of life.

 

Fast Span only would be good enough for me.

 

Honestly I would be more excited if Unity moved from mono to .NET 5

 

Whoops, you're right . Updated my answer immediately.

 

C# 8 brings simplified null checks, no more

Code (CSharp):

1. if (x is null)
2. {
3.   x = expression;
4. }

instead

Code (CSharp):

1. x ??= expression;

 

That is good news.
But will it comes with significant decrease of script compilation times?

 

Does latest Mono support .NET Standard 2.1?

Recently they've merged Mono to the very dotnet/runtime repository:
https://twitter.com/ben_a_adams/status/1218693139311009792?s=21
https://github.com/dotnet/runtime/pull/1912

 

Span<T> support turns out to be pretty important for compat reasons. As the .NET ecosystem shifts to .NET Core for everything this increases library dependencies on Span<T>. For example, System.Text.Json is the standard platform serializer for .NET Core. It won't run on Unity because it has a dependency on Span<T>.

 

There's plenty more than just that. https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8

 

@Lorash That's a good point. It's a widening fork that gets worse with time. ...Fast forward three years to the moment Unity announces an initiative to adopt .NET Core to address developer pain.

In Unity's defense, it's truly hard to live on the bleeding edge, especially when that edge is sharp and owned by someone else (Microsoft). Know of any MS tech cancelled unceremoniously? When the change to .NET Core does happen it will be a strategically safe bet for Unity.

 

Technically .NET is owned by the Foundation. Unity is a member of the Technical Steering Group so they have a reasonable amount of input to the future of .NET, I'd say it's very likely that their needs will be considered in future development - unlike the past situation where Mono was not owned by them at all, even partially, and .NET Framework was an entirely separate product.

 

Unity use a fork of the Mono runtime, this version is probably heavily personalized and deeply integrated in the core and make it difficult to replace.

 

After .NET 5 integrated into Unity, will it solve reload whole domain issue i.e. reload all the dlls including all the packages dll inside your project? I hope after this .NET 5 integrated, at least I just change one line of code it won't domain reload all the packages dll.

 

I wouldn't hope too much, on .NET Core you're limited to exactly one AppDomain and you can't unload it. We'll have to see how .NET 5 integrates Core and Framework, but I have a feeling it will lean towards Core of these two because that's the more modern one that runs on more platforms. Some kind of hot reload functionality like Unreal does could work better (although that one comes with its own heap of problems) and Unity has done the first steps with the new play mode options.

 

See AssemblyLoadContext. Also understand it, that's important too. Read this wonderful post as well. Additionally, CoreRT could eventually throw IL2CPP out the window. Why can't they just pause everything and move to .NET Core ASAP? That ought to make the .NET 5 update much less painful too. Oh, right, useless S*** like eye candy demos and visual scripting. F*** the actual programmers and editor performance, right? I wonder why Unity for AAA isn't really a well-established thing.

 

I'm all for having Unity run on CoreRT, but at the same time I don't think it will immediately solve the domain reload issue when your code changes. For that they need to do separate work on the way things are serialized currently. To be very clear I'm not against this at all.

Practically speaking my money is on when .NET 5 gets added into Unity it will be mostly as a direct Mono replacement (one of 5's stated goals is to be a viable drop-in Mono replacement), which will obviously come with immediate benefits such as the generational and compacting GC (that Unity is preparing for already) and better codegen.

 

Hmm... To be fair, I'm starting to question my understanding of domain reload and how `AssemblyLoadContext` would solve it... In any case, there's still the performance benefits of .NET Core. Even if that alone doesn't solve domain reload (it won't), it should still speed it up a fair bit.

From what I understand, they will have you choose which runtime to use instead of just merging all of them.

 

Any update on c#8 availability? Maybe in beta-preview version?

Thanks

 

I am starting a new Unity project and it is going to be based on DOTS.

From my researchs, DOTS are all about using structs instead of classes, however, structs cannot inherit from classes or even from other structs, so they are limited to interfaces. Without default interface implementation (available after c#8) I can see a big mess and multiple repetitions of code.

Having this feature seems to me obvious for a proper DOTS implementation, but maybe I'm wrong and there is a workaround.

Thanks!

 

Not so obvious for me. Are you going to access instances of your value types via references to the interfaces? Then you'll end up with a lot of allocations for boxed objects scattered throughout the managed heap — avoiding of which is the main (the only?) point of DOTS.

 

If you need a lot of inheritance, you think too much of OOP.
As exemple, if you have some component data that must have the same base date, do not inherit from a base, but split the shared properties to an separate component.

Default interface implementation work only for methods and you can use extensions on interfaces to share functionality.

 

I'm looking forward to C#8 for a few reasons (like using declarations and static local functions).
But, the most important thing for me is for us to have choice. Remember when we were stuck with obsolete compilers (and runtimes) and had to resort to all sorts of hackery? I don't want to have us moving in that direction ever again.

The current compiler is nice, but much nicer would it be for us to be able to use nuget to install Microsoft.Net.Compilers and we would have the latest compiler around.

I'm hopeful because Unity devs already replied to this thread positively and it seems the reason C#8 isn't here yet is due to runtime changes.

Happy to see more developers voicing their opinion here. Let's hope this can be used by the many dedicated Unity devs to justify getting extra resources to bring this feature to life.

 

Not going to start a debate, but I like OOP and it works for me. I hear the siren song of Unreal Engine calling for me...

 

I start the debate, an i would argue pure DOTS can be faster then Unreal with C++/OOP, but it's too early to compare them.

DOTS: Data-Oriented
OOP: Object-Oriented

These are two different program designs, force one into the other is not a good idea.
But i think, you can mix OOP and DOTS in a project depending on the task. The systems in ECS see for me like OOP.

 

.NET is very serious about backwards and forwards compatibility, way back to .NET 1.0. You can use a newer version of C# with an older runtime, you'll just miss out on certain features. For instance in a project that I worked on we were stuck on Framework 4.0 for a long time but that didn't stop us from upgrading to C# 5 and then 6, just with the knowledge that, e.g.,

await

would not work.

 

Never forget the first rule of optimization: don't do it.