Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice
  2. Enter the 2020.2 Beta Sweepstakes for a chance to win an Oculus Quest 2.
    Dismiss Notice

Unity C# 8 support

Discussion in 'Experimental Scripting Previews' started by Jes28, Apr 18, 2019.

  1. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    4,683
    Ahh, ok. From the Unity side, I don't expect that we will support Nuget soon though.
     
  2. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    18
    bdovaz, SINePrime and sand_lantern like this.
  3. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    4,683
    I wasn't involved in UPM at all, but I believe the Nuget did not meet some requirements UPM had.
     
  4. Neonlyte

    Neonlyte

    Joined:
    Oct 17, 2013
    Posts:
    259
    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.
     
  5. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    18
    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.
     
  6. scottpkane94

    scottpkane94

    Joined:
    Aug 24, 2019
    Posts:
    27
    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.
     
    Last edited: Jul 23, 2020
  7. aybe

    aybe

    Joined:
    Feb 20, 2019
    Posts:
    23
    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.
     
  8. unity_leuGqyZifU4AZg

    unity_leuGqyZifU4AZg

    Joined:
    Jul 3, 2020
    Posts:
    3
    @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.
     
  9. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    264
    I think it is 2020.2 with C#8 support.
     
  10. unity_leuGqyZifU4AZg

    unity_leuGqyZifU4AZg

    Joined:
    Jul 3, 2020
    Posts:
    3
    Ahh okay, nice!
     
  11. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    4,683
    Ahh true, this is not a final solution. I've presented this feature request to our scripting team - they are planning to implement it. I don't have an ETA though.
     
  12. Jorhoto

    Jorhoto

    Joined:
    May 7, 2019
    Posts:
    69
    can't wait for c#8 default interfaces :rolleyes:
     
    Neonage, Griz, Flavelius and 3 others like this.
  13. RamType0

    RamType0

    Joined:
    Sep 11, 2018
    Posts:
    17
    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.
     
  14. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    794
    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.
     
  15. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    166
    That requires manual conversion to the UPM format. It's native NuGet support that we need.
     
    Qbit86 likes this.
  16. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    794
    If you check that code, you will see that it converts on the fly (automatically) a Nuget package to the UPM package format.
     
  17. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    166
    That works, but native NuGet support would be nicer.
     
    Qbit86 likes this.
  18. idchlife

    idchlife

    Joined:
    Jul 25, 2016
    Posts:
    13
    Hoping C# 8 support will land soon! I'm used to nullable types in AspNet and Xamarin projects :D
     
  19. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    4,683
    It already exists in Unity 2020.2 alpha releases and later.
     
  20. PlayCreatively

    PlayCreatively

    Joined:
    Jan 25, 2016
    Posts:
    73
    I upgraded my project to 2020.2.0a21 (alpha) and it doesn't seem to allow C# 8 code. I get this error: upload_2020-8-23_3-27-8.png
     
  21. OndrejP

    OndrejP

    Joined:
    Jul 19, 2017
    Posts:
    114
    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?
     
    PlayCreatively likes this.
  22. TheZombieKiller

    TheZombieKiller

    Joined:
    Feb 8, 2013
    Posts:
    100
    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.
     
    PlayCreatively likes this.
  23. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    4,683
    We're working on it at the moment, but I don't have an ETA for default interface support yet.
     
    GilbertoBitt, Lelepoop and OndrejP like this.
  24. idchlife

    idchlife

    Joined:
    Jul 25, 2016
    Posts:
    13
    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
     
  25. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    438
    Will it be backported to 2020.1 ?
     
  26. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    4,683
    No, we're not planning to have C# 8 support in 2020.1.
     
    Prodigga and Thaina like this.
  27. van800

    van800

    Joined:
    Mar 10, 2018
    Posts:
    11
  28. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    477
    Huszky and Qbit86 like this.
  29. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    4,683
  30. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    18
    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?
     
  31. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    4,683
    That might be possible. In general though, we're trying to move toward support of more standard .NET BCL APIs, rather than adding one-of special cases. So I think our focus for the future will be directed at .NET 5 support instead.
     
  32. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    477
    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.
     
  33. Karashi-shiki

    Karashi-shiki

    Joined:
    Jul 9, 2019
    Posts:
    3
  34. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    625
  35. VolodymyrBS

    VolodymyrBS

    Joined:
    May 15, 2019
    Posts:
    8
    Already fixed:)
     
  36. jGate99

    jGate99

    Joined:
    Oct 22, 2013
    Posts:
    1,167
  37. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    18
    No, it only changes the compiler, and Default Interfaces require runtime support
     
    jGate99 likes this.
  38. jGate99

    jGate99

    Joined:
    Oct 22, 2013
    Posts:
    1,167
    Aah, i really hope Unity Team add Default Interfaces support.
    Thats the one BEST thing in C#8 IMHO
     
    Ghat-Smith likes this.
  39. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    18
    Well i suppose it wont come until net 5 and c#9 are around which they don't even have a public roadmap for
     
    jGate99 likes this.
  40. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    787
    I think its a dumb feature to be honest. Tying implementation to an interface.
     
    Qbit86 likes this.
  41. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    439
    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.
     
    PlayCreatively likes this.
  42. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    787
    A very narrow niche and it will for certainly be misused. So I stick to it being dumb :p
    But there are alot other cool things in C# 8 like async streams and nullables
     
  43. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    461
    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).
     
    EZaca and PlayCreatively like this.
  44. datagreed

    datagreed

    Joined:
    Sep 17, 2018
    Posts:
    34
    Damn, default interface method implementations were the only thing I was looking for in C# 8 :(((
     
    EZaca and PlayCreatively like this.
  45. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    787
    Haven't tried it in a while. But I have a hard time seeing default interface implementation being the solution to using unsafe pointers
     
  46. tmcdonald

    tmcdonald

    Joined:
    Mar 20, 2016
    Posts:
    112
    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.
     
    MDADigital likes this.
  47. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    787
    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.
     
    tmcdonald likes this.
  48. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,078
    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.
     
  49. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    787
    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.
     
  50. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    461
    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: upload_2020-9-17_16-19-48.png
     
unityunity