Unity C# 8 support

You can try above code to see that struct will not be boxed

If it boxed, the value would not be changed. It is not boxed with generic and ref

 

Actually, just try this https://dotnetfiddle.net/Inqku4

 

You can copy it from a Visual Studio installation (located in (Visual Studio Dir)/MSBuild/Current/Bin/Roslyn) and replace the one in Unity (Editor/Data/Tools/Roslyn). Then you can put -langversion:9 in a csc.rsp file to use C# 9.

The latest 2021 builds of the engine have already updated the compiler so you can use C# 9 without upgrading, but annoyingly there's no way to customize csproj generation. Unity places an explicit <LangVersion>8</LangVersion> in project files, so you need to keep modifying them to stop getting errors in Visual Studio.

 

You can also try using a csc.rsp file in the Assets/ folder containing

Code (CSharp):

1. -langversion:9.0

Edit: in newer Unity versions, it seems you can add compiler options using the editor.
Use Edit -> Project Settings -> Player, then scroll and add any options you need:

 

Awesome dude, thanks

 

Is there anywhere we can follow this and know if it's in or not?

 

how do you know so much forbidden unity knowledge
im too noob for any of this

 

Check this out: https://unity3d.com/unity/alpha/2021.2.0a11

 

This looks nice !
What about the support for code generators ?

 

What about default interfaces?

 

Those require runtime support, so you won't be able to use them with just a Roslyn upgrade (which has just shipped in the latest 2021 alpha).

 

Well I'm sad...
I wanted to use the new "function pointers", but it appears that just only adding such a function pointer makes the editor silently crash:
"public delegate*<int, bool> functionPointer;"

Do I have to do something special in order to make them work ? did you test that feature before releasing ?

Bug repported: (Case 1326082)

 

I'm only able to reproduce this crash if the field is serialized (meaning it's either a public field or a private/protected/internal field with a [SerializeField] attribute). Adding [NonSerialized] to the field causes the crash to go away. Serializing a function pointer doesn't make much sense so I assume this is just a case of Unity not filtering them out properly.

 

I tried that, and sadly it doesn't work for me.
I show you here a context where I wish to use function pointers.
I changed the code so that it would compile without my whole code (there's many more parameters to the function pointer in the real code, but it doesn't look like it affects the bug anyway).
The bug reproduces with the following code: a struct which is neither serializable nor intented to be serialized (in fact there's no reference to it in the code I use to test the bug).

I tried adding [NonSerialized] on the function pointer field, with no effect.

Code (CSharp):

1. public unsafe struct DataMatcher : IEquatable<DataMatcher>
2. {
3.     public int tokenId;
4.     public delegate*<int, bool> function;
5.  
6.     public DataMatcher(in int tokenId, in delegate*<int, bool> function)
7.     {
8.         this.tokenId = tokenId;
9.         this.function = function;
10.     }
11.  
12.     public bool Match(int i)
13.     {
14.         return function(i);
15.     }
16.  
17.     public bool Equals(DataMatcher other)
18.     {
19.         return tokenId.Equals(other.tokenId);
20.     }
21. }

 

I did a bit more testing, and your example no longer crashes if the type is changed into a class. So it appears that the crash-causing cases are:

• Serializing a function pointer (eg, by storing it in a MonoBehaviour, ScriptableObject or [Serializable] class)
  
• Defining a struct containing a function pointer

Other than changing the type into a class, I found that you can also use a property to work around the crash:

Code (CSharp):

1. public unsafe struct DataMatcher : IEquatable<DataMatcher>
2. {
3.     public int tokenId;
4.  
5.     void* pFunction;
6.  
7.     public delegate*<int, bool> function
8.     {
9.         get => (delegate*<int, bool>)pFunction;
10.         set => pFunction = value;
11.     }
12.  
13.     public DataMatcher(in int tokenId, in delegate*<int, bool> function)
14.     {
15.         this.tokenId = tokenId;
16.         pFunction    = function;
17.     }
18.  
19.     public bool Match(int i)
20.     {
21.         return function(i);
22.     }
23.  
24.     public bool Equals(DataMatcher other)
25.     {
26.         return tokenId.Equals(other.tokenId);
27.     }
28. }

 

Thank you for researching this !
Changing for a class will not do in my case as I want the type to be unmanaged, but using a property seems to be a valid workaround until this is fixed.

 

Ye, uh, so what's the status on that?

Or NET Core libraries?

 

just noting that I've tried the C# 9 function pointer in my Burst Job and I'm getting a
"Burst error BC1054: Unable to resolve type `method System.Int32 *(System.Int32). Reason: Unknown.". Filed a bug (Case 1326456)

I'm pretty much just casting an

IntPtr

->

delegate*<int, int>

and the error is appearing.

Here's the failing job:

Code (CSharp):

1. [BurstCompile]
2. public unsafe struct CallFuncJob : IJob
3. {
4.     [ReadOnly]
5.     [NativeDisableUnsafePtrRestriction]
6.     public IntPtr FuncPtr;
7.  
8.     [ReadOnly]
9.     public NativeArray<int> Input;
10.  
11.     [WriteOnly]
12.     public NativeArray<int> Output;
13.  
14.     public void Execute()
15.     {
16.         Output[0] = ((delegate*<int, int>)FuncPtr)(Input[0]);
17.     }
18. }

 

how likely is at the moment that this is going to happen @xoofx ?

 

Would it be backported to 2020? Can't use 2021 because we're using DOTS.

 

wow

 

Default Interfaces relies on all kinds of new compiler stuff that @JoshPeterson and his team are adding in 2021.2, so no.

Speaking of, can't wait for .NET 5 / .NET 6!

 

Great! Thanks! Super!

 

I'm a bit late into this thread. Is C#8 supported in 2021.2.21> ? Thanks, Marek.

 

Yes, C# 8 has been supported since 2020.2.0a12, and newer versions now have partial support for C# 9.

 

C# 8 is available since 2020.2

 

You're right, I didn't even notice I made that typo.

 

C# 8 is not really supported in 2020.2, since it is missing a core feature: "Default Interfaces" which is available (as stated above) in 2021.2.0a21 version.

 

I installed 2021.2a21, but have the error: Target runtime doesn't support default interface implementation.

 

based on this answer https://forum.unity.com/threads/unity-future-net-development-status.1092205/page-3#post-7225384 I assume that BCL not updated to NET Standard 2.1 yet. So compiler does not know that runtime support default interface implementation.
Compiler detect that runtime support this feature by checking if

 System.Runtime.CompilerServices.RuntimeFeature.DefaultImplementationsOfInterfaces

exists.

 

I see the same (Target runtime doesn't support default interface implementation).

You mean this?

##### CommandLine

"C:\Program Files\Unity\Hub\Editor\2021.2.0a21\Editor\Data\NetCoreRuntime\dotnet.exe" exec "C:/Program Files/Unity/Hub/Editor/2021.2.0a21/Editor/Data/DotNetSdkRoslyn/csc.dll" /nostdlib /noconfig /shared "@ Library/Bee/artifacts/1900b0aEDbg.dag/com.lurkingninja.eclypsia.rsp"

Note: There is no space between the @ and the Library, but the forum tries to link to a forum user so added.

Spoiler: More log parts

##### Contents of Library\Bee\artifacts\1900b0aEDbg.dag\com.lurkingninja.eclypsia.rsp
-target:library
-out:"Library/Bee/artifacts/1900b0aEDbg.dag/com.lurkingninja.eclypsia.dll"
-refout:"Library/Bee/artifacts/1900b0aEDbg.dag/com.lurkingninja.eclypsia.ref.dll"
-define:UNITY_2021_2_0

[...]

-langversion:9.0
/deterministic
/optimize-
/debug: portable
/nologo
/RuntimeMetadataVersion:v4.0.30319

[...]

##### Output
Assets\_Eclypsia\Code\Interfaces\ILoopInterface.cs(5,14): error CS8701: Target runtime doesn't support default interface implementation.
*** Tundra build failed (1.19 seconds), 1 items updated, 845 evaluated
Assets\_Eclypsia\Code\Interfaces\ILoopInterface.cs(5,14): error CS8701: Target runtime doesn't support default interface implementation.

 

I made a minimal reproduction project.

Case number: 1343996

 

I am getting the same issue as the others,

Code (CSharp):

1. ##### CommandLine
2. "C:\Program Files\Unity\Hub\Editor\2021.2.0a21\Editor\Data\NetCoreRuntime\dotnet.exe" exec "C:/Program Files/Unity/Hub/Editor/2021.2.0a21/Editor/Data/DotNetSdkRoslyn/csc.dll" /nostdlib /noconfig /shared "@Library/Bee/artifacts/1900b0aEDbg.dag/Assembly-CSharp.rsp"
3. ##### Contents of Library\Bee\artifacts\1900b0aEDbg.dag\Assembly-CSharp.rsp
4. -target:library
5.  
6. -out:"Library/Bee/artifacts/1900b0aEDbg.dag/Assembly-CSharp.dll"
7.  
8. -refout:"Library/Bee/artifacts/1900b0aEDbg.dag/Assembly-CSharp.ref.dll"
9.  

All of my coworkers are having the same problem as well.

Cheers,
Z.

 

It can be voted and followed here: https://issuetracker.unity3d.com/issues/default-interface-implementation-error

 

This is how all of the Unity technical communication should be. It's clear and explains the setback in a way that devs understand and can sympathise with. Thanks for the update @JoshPeterson.

 

@JoshPeterson thank you for communicating like this to us, I wish all other teams did it like this as well.
It's good to know what's going on behind the scene and what we can expect.

 

Thanks for the update! Do you happen to have a estimated release data for b6?

 

I suppose then that this thread is coming to its end, while the Unity Future .NET Development Status thread has only just begun.

Unless you have even more threads that I don't know about