Will the final ECS release wait for C#8 / .NET Standard 2.1 ?

Several blogs came out to preview features of C# 8. One of them even said that "Unity and Mono will all implement .NET Standard 2.1".

https://blogs.msdn.microsoft.com/dotnet/2018/11/12/building-c-8-0/
https://blogs.msdn.microsoft.com/dotnet/2018/12/05/take-c-8-0-for-a-spin/
https://blogs.msdn.microsoft.com/dotnet/2019/01/24/do-more-with-patterns-in-c-8-0/

I wonder if ECS will wait for this and try to add C#8 feature into the library before release? If this is the case then going forward, to use ECS the target framework must be .NET Standard and not .NET Framework 4.x. If I can know that is the plan, then I would start trying to get my game compatible with .NET Standard 2.0 today to minimize pain later moving to 2.1.

One very relevant feature is default interface implementation. I think it has potential to redesign IJob and others, which will be a big deprecation again if it is happening, but if you are going to do it it is better be in this preview phase.

 

A lot of the features still remain available to 4.x, the features that don't seem to be OOP variants.
Using interfaces is generally a bad practice, if they have too much going on that is, but I am unsure where you think the IJob would need a redesign. It could be reshuffled to a more solid Job class or interface, even letting the JobComponentSystem implement it might be beneficial on reducing the amount of code needed, but thats more "altering the future" and if its in a state it needs refactoring now it would have been designed poorly, so I trust its usage is as planned.

Theres only Execute inside IJob, thats the only method available to that interface, which is fine. But in terms of where I was saying the only place to push for a refactor on that would be to eliminate the need for an interface and place it in a solid Job class.

In my experience through C++ having interfaces create lazy programmers, where they will create an interface, then push all their functionality into there where they don't want to put in the effort to pull up another interface or rethink their implementation so that all these interfaces could just be specific to one object and they inherit a general set of functions from a parent while adding their own to the child.
Having default implementations there make it even worse because one programmer will set up a default that all objects can run... Then another will come over because the task has been passed over or they need to do something with that interface, and suddenly implement that default one causing mayhem.

Of course, someone who is actually working on the job system will need to step up and say Yes or No. Just my thought on the C#8 stuff

 

That is simply incorrect.

 

I have no idea, but the design team might have something in mind. To admit, the current HPC# design is quite ingenious. Close out sources of aliasing problem as much as possible with struct and interface as a base, then patch the remaining holes with runtime code analysis.

 

Even if they don't redesign it, default interface implementations will make it easy to share code between jobs. I believe you would be able to put the Execute implementation on the interface and then just inherit it in any job. Just fill in the generics and you're done.

 

All I know is that a ton of games use libraries and frameworks that only support standard 1 or 1.6. Even MS sponsored projects I use took months to support 2.0, and some are still on 1.6.

If I had to move to standard 2.0 in Unity I'd face major engineering having to implement libraries I currently use.

C#8/.Net core 3 is I imagine at least a big a leap as standard 2. I would think .Net core 3 is what will drive most of the adoption, not the language itself. My experience is language features are a nice to have mostly. If they come at the cost of significant engineering the benefits evaporate really fast.

 

If I had to guess, I'd say that by the time C#8 is mainstream, Unity will likely put out a .Net Core target. IL2CPP is nice but core is going to continue to win when it comes to performance. And .Net Core 3 seems like an obvious starting point for a Unity core target.