Unity C# 8 support

Yeah. I've used C#6 with Unity way before they had it officially (thanks to @alexzzzz and SaladLab), with knowledge that some features would not work.
Let's hope Unity will figure out a way to decouple the compiler further so that we could at least have the newest sugar.

 

.NET CORE major releases are no longer backwards compatible, there are breaking changes here:
https://docs.microsoft.com/en-us/dotnet/core/compatibility/2.2-3.0

 

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version


https://docs.microsoft.com/en-us/dotnet/standard/net-standard

 

So far i know, you can use C# 8 also with older frameworks, but with limited features.

 

That's intense.

It seems we'll be left behind again, like in the old times, unless Unity can move to Core.
Let's hope they figure something out, especially with many developers chiming in and voicing support for newer and more decoupled runtime/compiler.

 

According to this Microsoft blog post, it seems Unity will have standard 2.1 at some point.

According to this github issue from July 2019, they are thinking it will take about 2 years for it to come around, so it might take a while still.


But it's real and it seems to be coming, so we rejoice!

 

It definitely will but most seamless move will be in .Net 5 where we have most of .Net Framework features.
So it hard to believe than we will have something new (officially) before .Net5 and Unity 2021 may be preview in 2020 I think

 

Do you consider to get rid of mono and IL2CPP in favor of .Net 5/Core and .Net 5/Core AOT in some future?

 

IL2CPP is necessary for certain platforms where JIT is not allowed.
I heard that DOTS runtime should support .net core in the future.

 

If you guys can decouple the compiler a bit more, I think many of us would already be a lot happier with having only the new sugar (like using declarations, switch expressions, etc). I think only default interface methods require an actual runtime change with no chance of a polyfill.

 

Exactly for those platforms .Net 5/Core AOT exists

 

But hey, I can launch Visual Studio, create a new NET Framework 2.0 project, switch C# version to 8.0 and use its features that work and don't use those that don't.

For example, this code runs fine:

Code (CSharp):

1. using System;
2.  
3. class Program
4. {
5.     static void Main()
6.     {
7.         Foo();
8.         static void Foo() => Console.WriteLine("static local function");
9.     }
10. }

This one produces CS8701: Target runtime doesn't support default interface implementation.

Code (CSharp):

1. using System;
2.  
3. interface Program
4. {
5.     static void Main()
6.     {
7.         Foo();
8.         static void Foo() => Console.WriteLine("static local function");
9.     }
10. }

It's not that the program crashes or works the way that's not expected. There's no confusion. The compiler explicitly says that the runtime doesn't support this exact feature. Ok, thanks, I won't use it then.

If it works for NET Framework 2.0, why can't it work the same way in Unity?

 

Awesome info @alexzzzz
I remember reading that they did something like that but could not find the article when I looked for it earlier today.
I was going to try again now, but I see that you're already on the job!


There's a lot of cool stuff with the newer compilers, even if its just the syntactic sugar.
This also brings parity to those of us that use codegen or otherwise depend on Roslyn's csc directly.
It means everything is being compiled by the same toolset.

 

This is basically what I suggested in another thread - if default interface implementations are difficult that's fair enough but there are plenty of C# 8 features that come "for free" from Unity's perspective and are implemented entirely in the compiler.

 

I think this may open a new can of worms for making a partial support of C# 8:

- The release note have to be very specific on what feature is missing, but longer the release note the more likely the message would be misinterpreted.
- Unity would need to implement a way to check whether a feature is being used to generated error messages, maybe by replacing code in the compiler. When the runtime is fitted in, they'll have to reverse the change, and that's extra work.
- Other dev tools may not be aware of the feature missing, and code that looks fine in the IDE may cause compiler error in Unity, leading to confusion. This is already happening if Roslyn Analyzer is turned on in VS Code -- VS Code would suggest refactoring tips for C# 8 features (unless there are settings I can change) but Unity is on C# 7.

I still remember in Unity 5.X days where I would get extremely confuse about what .NET version Unity supports. There are indications that Unity targets .NET Framework 2.0, but in practice it was .NET Framework 3.5 with some feature missing, and I never been able to figure out what things are missing. It is only until 4.X support is introduced that I can use Microsoft's documentation without needing to guess whether it would be missing.

To be fair, C++ compilers have been rolling out partial implementations of a standard frequently. I do see the benefits of making new features available ASAP.

I wonder what C# 8 features are in high demand? My work has not required me to try them out.

 

Is it really that hard to clearly state "Default interface implementations are not available"?

As mentioned, the compiler emits an error if a feature isn't supported by the target runtime. It can't be that hard to tell the compiler that it's targeting an ancient runtime equivalent to an official runtime version that doesn't support default interface implementations.

Probably nullable reference types. Not that I don't have the feeling that it wouldn't be very useful because of Unity's custom == operator or anything.

 

Not just NRT (which, even without Unity types being properly annotated, can still work with third-party libs) but also switch expressions, static local functions, and my personal pet peeve ??= is finally no longer missing from the language.

It would also be nice, especially for Unity with its subpar GC, if the missing pieces for the expanded stackalloc support in C# 7.x / 8 were added so you could have more/easier ways to avoid allocations (mostly Span<T>, even if it's the less efficient variant with three members).

 

Keep up the good fight, thanks for everything you guys do!

 

Josh, thank you for your service to Unity and its community. I appreciate the way you listen and your candor in helping us achieve our goals.

 

Am still waiting to have C# 8.0 support in Unity, have been using it with my other non-Unity projects and I love the new features: which I am still waiting to use those in Unity

 

Using C# 8 features that don't require runtime support was easy enough on Linux. I just replaced the unity_csc.sh script with one that calls my system-wide dotnet core compiler.


AFAIK this should be fine, Unity doesn't use a custom compiler(?), just a customized mono runtime.

 

It's a little more mysterious on Windows, there are multiple instances of csc.exe. There's also VBCSCompiler.exe.

 

That also works on Windows (at least when I quickly tested), but I'm weary of using it because I don't really know what changes Unity did to csc and I'm not 100% sure that the unity_csc script is the only entry point in the compiling chain. Unity has never been very respectful with entry points.

 

Yeah, if there was an easy hook to get a newer Roslyn in I'd happily do it at my own peril, but it seems a little dodgy, plus I have multiple machines running builds, etc. so I'd need to redo this at every Unity update.

 

There seems to be only a single instance of unity_csc.bat on windows, so you can probably be pretty safe that that's the one used.

That one points at Editor/Data/Tools/Roslyn/csc.exe, which is the only one that will run if you try to run it in Powershell (the other two copies can't find System.IO.FileSystem).

 

Excelent news!
Keep up the great work!!

 

Any hope on supporting csporj to be commited to version control and nuget support with the c#8 and .Net 5 craze?

 

The csprojs are ignored by Unity and I'd personally estimate the likelyhood of NuGet support to be extremely low - Unity reinvented their own wheel for packages so management will be pushing hard for improvements/etc. in order to not have to admit that it was a mistake.

 

Does unity has any technical reason why aren't they planning on supporting this? The Microsoft Mixed Reality Toolkit team has already achieved this with https://github.com/microsoft/MSBuildForUnity . If a few Microsoft employees can achieve this bandage over the old build system I can't imagine the Unity team could not pull it off in a couple of week. Also it would play nicely with the .Net 5 support which is as we know you are working on.

 

I was very excited and immediately started to try out this one. After having to hack around to even have the package (their instructions don't work), the generated csprojs were invalid and my entire project was broken. I would love to use an alternative build system (VS builds my project in a fraction of a second, Unity 2019.3 takes up to 10 seconds), but this is not it.

 

I’m a little late to the party, but…

Given that the project and solution files are auto generated, could you not add a custom Analyzer for .Net Compiler Platform that marks any unsupported language features as an error, thus preventing the use of those features while still allowing use of latest language / .Net versions? This approach could provide you guys with a little more breathing room when new versions are release.

 

Unity 2019 is not yet supported https://github.com/microsoft/MSBuildForUnity/issues/136

 

But we still won't see it anytime soon...

 

Please forgive my ignorance; If this is the case, then why cant we use C# 8 now?

Is this something that we (the community) can override via a package or is it hardwired into Unity?

 

You can override it by going into the Unity install directory and swapping the Roslyn that they ship with the latest version. If you can do this, great, but there can be reasons why you can't do that (in my case it's less pain sticking with C# 7 than having to ensure all the dev and CI machines keep getting the Roslyn hack whenever I decide to take a Unity update - this might change during LTS though).

 

This might be a little bit off topic but one of the main reasons I'm following C#8 threads here is because I'm waiting for a fix for this issue. It's fix apparently related to new compiler feature, custom DiagnosticSuppressor.
Since C#8 (and its newer Roslyn compiler) is closer to shipping than initially anticipated, I think this issue can finally be moved up tasks list

 

Really looking forward to being able to use mixins with C# 8, it should really help us keep our architecture more clean.

 

That's the difficult one to implement from Unity's side.

 

So far the feature I yearn for the most is inline using statements
This way I can finally have RAII like in c++ YAY

Code (CSharp):

1. {
2.     using arr = new NativeArray();
3.     // Disposed! No leaks, no additional nest level!
4. }

 

I am most interested in nullability. I use defensive programming for visual related code as I do limit the amount of tests when it comes to 3D related code. I come from the strict TDD corner and applying it to 3D code would result in an excess of automated tests. Currently most of the non-performance-critical methods read like this:

Code (CSharp):

1. public void doSomething(Type parameter) {
2.     notNull(parameter, nameof(parameter));
3.     ...
4. }

It is okay to verify everything that comes in and most that goes out but being able to just do doSomething(Type? parameter) would eliminate most of my notNull checks.
.

 

Default interface implementation is the top-notch feature for me. It can totally change your current game/framework architecture. Hopefully we can put hands on c#8 in Unity soon

 

I am a little confused... you can already create nullables like float? in Unity, for a long time actually. Which version are you using?

I have to thank you though! Because I was confused, I looked up nullability and found the C# 8 null-forgiving operator, which I now HAVE to have! https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-forgiving

This will allow code like this:

Code (CSharp):

1. public float GetX(Vector3? v)
2. {
3.     v ??= Vector3.one;
4.     return v!.x;
5. }

Of course there are other ways to solve 'that' particular issue, but the point is that you can tell the compiler "Hey man, I am SURE this nullable value is not null."