Unity C# 8 support

I have made this project which works most of the time: https://github.com/KuraiAndras/UnityCsprojNuget
Also there is https://github.com/microsoft/MSBuildForUnity but it does not seem to work with Unity 2019 and up
Also i don't really understand why unity went all the way to develop UPM when the .net ecosystem already has a package manager...

 

IMO I am not sure if I want Unity-specific libraries to be distributed on NuGet, simply because they would not work for other non-Unity projects without Unity's core library also available on NuGet, because NuGet packages are expected to declare their dependencies. If one publishes such libraries and someone consumes them, they may find that the libraries causes compilation failures, which may lead to a lot of confusion (I don't expect everyone to read through the details on nuget.org...)

If I want to get Unity-specific packages from NuGet, I would expect Unity to ship their core library onto NuGet and make sure they compile and run standalone without Unity Editor/Runtime. Given Unity has a lot of things, someone may pull Unity as a dependency in their non-Unity project by accident, and it would also cause confusions.

 

This is not an actual issue. This kind of thing already happens with Windows only nuget packages which have precompiled dlls or old Net Framework nugets. When Core released nobody complained that they cant consume Windows only packages on Linux, so they want a new package manager.

 

IMO we should just have nuget integrated as another option for packages, because it doesn't interfere with unity packages, only additional third party code. You guys would also know which System assemblies come as part of the engine so could just block them from being re imported which makes everyone's developer experience better.

 

It only fixes half of the problem actually,

You will still get the following warning:

warning CS8669: The annotation for nullable reference types should only be used in code within a ‘#nullable’ annotations context

By the way, doing only that would already make VS happy, though doing so from RSP triggers warnings on whole project as bonus.

 

@JoshPeterson Since it has been close to a month since last update, and Unity has shipped 2020.1.0f1 (which I'm pretty sure claimed it supports C#8), any update on C#8 working? Unity still generates 7.3 csproj files for me.

 

I think it is 2020.2 with C#8 support.

 

Ahh okay, nice!

 

can't wait for c#8 default interfaces

 

Don't you think it's barren to port "Mono.Cecil" or "NewtonSoft.Json" to UPM, or to have your own equivalent just to resolve assembly conflicts in "System.Runtime.CompilerServices.Unsafe"?
Add NuGet support or publish a converter to UPM.

 

https://github.com/xoofx/UnityNuGet

It's from a Unity employee @xoofx

It should be maintained officially to have a better way to handle common dependencies between UPM packages.

 

That requires manual conversion to the UPM format. It's native NuGet support that we need.

 

If you check that code, you will see that it converts on the fly (automatically) a Nuget package to the UPM package format.

 

That works, but native NuGet support would be nicer.

 

Hoping C# 8 support will land soon! I'm used to nullable types in AspNet and Xamarin projects

 

I upgraded my project to 2020.2.0a21 (alpha) and it doesn't seem to allow C# 8 code. I get this error:

 

Default interface implementation is not just about C# compiler, it requires runtime support.

Unity has to upgrade to new Mono version - or use different runtime like .NET Core (unlikely to happen soon)
And implement default interface implementation into IL2CPP

@JoshPeterson Any idea when this might happen?

 

It's caused by the Visual Studio IDE package. For some reason right before Unity got C# 8 support, they added some functionality to it that forces projects to C# 7.3. There have been further updates to it after that, but none of them have addressed it, unfortunately. That said, as stated by OndrejP, even after this gets fixed you won't be able to use default interface implementations in particular.

 

Thanks! Yes, I saw this in comment earlier. But I'm sitting on 2019 LTS, because I'm too afraid to encounter serious bugs in my production ready projects

I suspect I will be able to hop on 2020 train in half a year or something, when LTS release will be available

 

Will it be backported to 2020.1 ?

 

fyi https://youtrack.jetbrains.com/issue/RIDER-50960

 

Which one is true for Unity 2020.2 ?
https://blogs.unity3d.com/2020/09/1...s-now-available-and-we-welcome-your-feedback/

Or:

Net standard 2.0 from https://stu.dev/csharp8-doing-unsupported-things/ :

 

Couldn't the category 2 problems be solved by adding https://github.com/bgrainger/IndexRange (or something equivalent ) and Microsoft.Bcl.AsyncInterfaces by default to unity?

 

There are still more important dlls that were already in C# 7:
System.Buffers
System.Memory
System.Threading.Tasks.Extensions
System.Runtime.CompilerServices.Unsafe

I wish these would be included as otherwise plugins have to ship them. They can't use package manager as they would clash with each other, for ex https://github.com/neuecc/MessagePack-CSharp

It was the case with DOTS and System.Runtime.CompilerServices.Unsafe but fortunately dll was removed at some point from package.

 

This package allows us to build C# 8.0 code even Unity 2020.1 or earlier.
https://github.com/mob-sakai/CSharpCompilerSettingsForUnity

 

Good package, encouraging
But dont work for Unity 2019.4.9

 

Already fixed

 

Can we use it for Default Interfaces Support?

 

No, it only changes the compiler, and Default Interfaces require runtime support

 

Aah, i really hope Unity Team add Default Interfaces support.
Thats the one BEST thing in C#8 IMHO

 

Well i suppose it wont come until net 5 and c#9 are around which they don't even have a public roadmap for

 

I think its a dumb feature to be honest. Tying implementation to an interface.

 

It's not dumb and has its own very narrow niche. But as far as I can see everyone can't wait to start misusing it for traits or something.

 

A very narrow niche and it will for certainly be misused. So I stick to it being dumb
But there are alot other cool things in C# 8 like async streams and nullables

 

If you already tried the DOTS packages (Entities and Jobs, more specifically) then you will know that there are great use cases for that that currently requires ugly workarounds (such as unsafe pointers everywhere).

 

Damn, default interface method implementations were the only thing I was looking for in C# 8 ((

 

Haven't tried it in a while. But I have a hard time seeing default interface implementation being the solution to using unsafe pointers

 

Does default interface implementation give you anything that you can't already do with extension methods? We've done some factory pattern setups using an empty interface and various extension methods in different nugets depending on what infrastructure you were using (for example, we had an ICache interface, and the factory for it was in a static CacheFactory with an empty ICacheFactory with a nuget for an extension method that would allow you to create it using Redis cache, another for an HTTP Restful cache, and another for an in-memory cache for testing.)

I guess I see that you can have non-public default implementations on an interface but that kinda seems like a code smell to me, but I could be totally missing something.

 

I have done the same for APIs i have created, example here a API for SingalR

Code (CSharp):

1. app
2.                 .UseEventProxy()
3.                 .UseSignalREventAggregator();

https://github.com/AndersMalmgren/S...ggregatorProxy.Demo.AspNetCore/Startup.cs#L93

Implementation

Code (CSharp):

1.  
2. public static IApplicationBuilder UseEventProxy(this IApplicationBuilder app, string eventsUrl)
3. {
4. app.Map(eventsUrl, subApp => subApp.UseMiddleware<EventScriptMiddleware>());
5. return app;
6. }
7.  

Ok So I see a couple of problems here moving this to default interface implemnetation.

Im not even the owner of IApplicationBuilder its a microsoft owned interface. So I cant add any default methods to it. Second doin so would be extreme bad seperation.

 

The reason they were added was so that you could add new functionality to an interface in a backwards compatible manner.

So you have a library, and you want to add a method to an interface in that library. But a bunch of people have your library as a part of their apps, and are implementing that interface.

Before default implementations for the interface, they have to update their app to update your library. But now you can implement a default implementation, so they're good.

At least from the marketing material I have seen, that's the reason why the feature was made. If that's what it's going to be used for is a totally different question! I have seen talk about being able to make mixin-like interfaces in C#, which is a feature that a lot of people like from other languages.

 

That makes no sense though. The implementation behind that interface is a blackbox to the library developer. There is no way he can implement a default behavior on that interface that will work for even a small part of its consumer base.

And if he could find a good default behavior for it then it was probably not a good candidate for that interface. If we know what something will do, there is no need for abstraction.

 

Currently if you want to have a base job type and "inherited jobs" from it, you need to create hacky workaround, such as creating a pointer to the "base type", or creating an interface + extension methods for that interface to make it work as desired. Here is a pratical example: