C#7 Support

2018.2.0b7 changes mentions:

• Universal Windows Platform: Updated Roslyn C# compiler used for script compilation on UWP and Xbox One to version 2.7, which supports C# 7.2. (1004854)

Is there a way to enable this for other build types - (particularly IOS) ?

Previous Discussion:
https://forum.unity.com/threads/c-7-support.512661/

C#7 Support Plugin:
https://bitbucket.org/alexzzzz/unity-c-5.0-and-6.0-integration/downloads/

Mono C#7 Epic
https://github.com/mono/mono/issues/6854

 

You could give the incremental compiler package a try. God knows why they put the thread for it in the ECS/Jobs sub-forum but it's completely separate.

"Built using Microsoft's Roslyn open source compiler project, our new C# compiler is designed to dramatically accelerate iterating on your C# code as well as giving you access to the latest and greatest C# 7.2 features."

https://forum.unity.com/threads/unity-incremental-c-compiler.523993/

 

This makes me beyond ecstatic, keep up the great work

 

That means there will be no Mono backend, right? Or there will be Mono with it's bad GC?

 

Is a new Garage Collector finally rolled out?

 

Compiler has almost nothing to do with the runtime.

The old compiler was the "Mono C# Compiler". Now we'll get "Roslyn" (that new c# compiler, which by the way is also the thing at the core of the "Incremental Compiler" unity package). The compiler simply turns C# source code into MSIL assemblies (dll files).

The "backend" / runtime will still be mono. Most new C# features don't require any changes to the runtime at all, thats why all those fancy new C# features still work. (Some of you guys also use IL2CPP as a backend, but that's something else again).

The "api compatibility level" setting in unity only determines what assemblies are fed to the compiler (no matter what compiler that is) to enable some newer APIs.

The garbage collector will still be the same old thing we had for years with no new thing coming in the forseeable future. It was mentioned once or twice that the guys at unity are looking into upgrading the GC to something more modern though. For example switching from the current mode (called "mark and sweep") to a newer one (called "generational").
Generational is basically mark-and-sweep but it has 2 or 3 different pools, and objects that survive a garbage-collection will be promoted to a higher pool (think of it as pools named "objects that die quickly" and "objects that seem to be here to stay").

 

It's sad to see Unity not giving high priority to get a new GC.

 

Because they are trying to move very heavy code to non-GC area with ECS, Jobs and Burst.

Like there will be a lot of non-GC code with a small GC area. I think they are doing it right.

 

They are giving it max priority already. There are TONS of things that have to be done before a switch to a newer GC is really possible though. It's one of the core components of the runtime that can't be easily messed around with.
We know they have started internal tests with a different GC implementations, but there is still a lot of groundwork to be done. So don't worry, we're getting there.
It's just not as easy as people think. It's not like you just drop in "BetterGC.dll", quite the opposite actually, lots of moving and interacting parts here...

Getting a better GC is unavoidable though.
The amount of time people have to spend to get rid of lags from the GC is enormous.
There are many GDC talks on youtube of people talking about what work they went through just to make sure games don't lag on slower platforms (consoles or smartphones).

Sure ECS will have the advantage of having explicitly managed memory, but not everyone can or wants to use them.
Some games (like mine) can at most port a few auxiliary systems to ECS (and I did), but the majority of things are so complicated that it wouldn't be worth the effort, or sometimes its even entirely impossible (*).
Also lets say your requirements change, you want to add a new feature, or you see that some feature needs to be changed, then scrapping all the work you invested + getting everything to work in ECS is more work than writing code the classic way (using MonoBehaviours on things) and then optimizing out some performance-critical sub system IF there's even need.

My point is:
ECS is awesome, and a much needed (for many use cases even essential) part of unity.
But it is NOT a silver bullet that solves all your problems.
It is another tool.
One that has (exactly like every other tool in a developers toolbox) many many places where it is simply not useful.

</rant>


(*) Can't avoid string allocations by using ECS. Can't avoid allocations from serializers/deserializers unless they support it, and ECS is not help there.
Can't avoid allocating state-machines from IEnumerator/Task, variables captured into lambda expressions, ...