Unity Future .NET Development Status

I would be interested to know what challenges the team is facing right now though. It was my understanding that you were currently closely working on updating the GC (which was a requirement and huge improvement), and I also remember there being talk of a CoreCRL build working on an empty unity project which would probably need a lot of R&D to get it up to production-ready level.

But this thread is so long now and I can’t tell what’s real anymore so it might just all be in my head

 

unrelated to this thread, but still huge (posting it here for more people to see): https://github.com/dotnet/csharplan...M-2023-03-08.md#limited-breaking-changes-in-c

 

Oh man, if we do get breaking changes and some form of field accessor, imagine this:

Code (CSharp):

1. [field: SerializeField, Range(0f, 1f)]
2. public float myFloat
3. {
4.     get => field;
5.     set => field = Mathf.Clamp01(value);
6. }

My code-loving heart would explode <3

 

That will definitely come, I think semi-auto properties were already in a C#11 preview. Maybe they'll make it to C#12.

 

yeah the field keyword for properties will absolutely come, which is also great, but

I wanted to draw more attention to the incredibly awesome possibility of getting something similar to rust editions. That would be SOOOO huge.

 

What would be the difference with:

Code (CSharp):

1.  
2. private float field;
3. [SerializeField, Range(0f, 1f)]
4. public float myFloat
5. {
6.     get => field;
7.     set => field = Mathf.Clamp01(value);
8. }

Just the extra line? what am I missing?

 

Nothing, I was just excited about the extraless line

Although it is a lot nicer I think to not have to manage your fields and properties separate in Unity all the time, especially when they are far apart for organization, or if you change your setter you have the attribute right there instead of having to remember to change it. It also happens alot where I change an auto-property to a custom-property and NOW I have to move my attributes, write a WHOLE extra line, scream in a pillow, all that jazz... truly I cannot wait for the utopian future where I won't have to do that.

But seriously this is a happy day for OCD-ers and neat-freaks.

 

I feel like C# is evolving too fast with these syntax conveniences. It's not (yet) as bad as C++, but it all seems unnecessarily complex, especially for new users learning the language, or for collaborating.

For example,

if(array != null && array.Length > 0)

can now be written as

if(array is { Length > 0 })

-- which at first glance looks like a NullReferenceException waiting to happen, unless you know the null check is implicit in the syntax.

Similarly,

array != null ? array.Length : 0

is now

array?.Length ?? 0

, which is a few keystrokes shorter and much more awkward for anyone not familiar with null coalescing. It's also more IL instructions, which probably won't matter in CoreCLR, but might for Mono or IL2CPP.

You can ignore them, which is all fine and dandy until you need to read/debug someone else's code. Or JetBrains Rider decides to channel its inner Clippy and suggest them as "improvements".

Plus,

readonly ref readonly Foo

just makes me cry tears of

const Foo const *

.

I'm not against introducing breaking changes to C#, but is the "field" thing really useful enough to warrant them? Woe betide anyone making a reflection wrapper, GUI system, elecromagnetics simulator, or sports game, where "field" might actually be a legit variable name.

 

Heavily disagree. Any single one of the new C# features are incredible and produce more expressive and concise code. Furthermore, you seem to not understand proposed features like the 'field' keyword for properties - because that's exactly what it is, a new keyword in the context of being INSIDE of a property block. Of course you can still name your variable 'field' if that is appropriate for you, nothing at all changes there.
Even if - which will not be the case - the 'field' keyword would stop you from naming your variable, you could very simply just follow the same convention of naming your property as any other keyword overlapping variable does: 'enum' -> '@Enum'.

 

I find that the majority of them are so limited in the places they make code more expressive. Yes, in isolation, they can all be argued to be positive, but each one adds new complexity and increases the barrier to entry for new users. Several of them are unintuitive at first glance.

Why do you say that I "seem to not understand" it? Did something in my post suggest that?

I know that it's limited to the scope of a property block, and within the property block, and that you can access a field named

field

by using

this.field

-- *if* you're writing your code for the first time in C# 12, and know about the change (eg follow all the latest blogs). That's a quite small audience. For anyone who's not following the latest trends, and has tons of legacy code -- I'd argue the vast majority of engineers will fall into those categories -- it's a newly introduced bug plus a warning that you'll hopefully notice.

The advantages it provides are clear. It saves you from needing to explicitly type out a property (saving a few keystrokes). It also makes copy-pasting or duplicating lines of properties easier. Even if it didn't break existing code, those advantages are fairly inconsequential, and IMO not worth the increased complexity. The fact it introduces a subtle bug in existing code only makes it worse.

I love C#, I'd much rather work in it than an extremely limited "pay by the line" language like Go (which I used a bit at an old job). But there's a middle ground between throwing in every proposed feature and being deliberately limited. C#'s recent decisions (over the last 5-10 years) have been to say "yes" to most proposed syntax conveniences, without considering the costs of increased complexity. This type of feature doesn't add functionality -- or even, I'd argue make your code more "expressive" -- it just saves some typing.

 

It will also allow a source generator to provide an implementation for a property without any possibility of conflicts with existing fields/members in the type, once partial properties are implemented.

The language design team are also well aware of the bug potential, they don't add these features willy-nilly. Much consideration has been put into this area and the recent proposal mentioned earlier in this thread covers the concerns you have (the tl;dr: when you compile code using a newer C# compiler, and it detects that some of your code would change in behavior under a newer language version, it will give you a warning).

Personally I don't see "existing programmers don't know about it" as a strong argument. Of course they won't! It's a new feature. We have documentation and Google to solve that problem. I can search "C# double question mark" and the answer is right in front of me -- and if a programmer is not willing to learn, the problem isn't the language in that scenario.

 

@burningmime this ^^ x 10

any feature that was added to C# has been carefully thought out by the language design team before ever being added. and even features that were already implemented and still turned out to be undesirable in hindsight, like the argument-null-exception-bang, were promptly removed from C# again.
I can say with full confidence that there is not a single language feature of C# that i haven't used and wouldn't miss.

 

That proposal also shows an exisiting way around it: the

__generated_

thing.

field

is a much more common member name than

__generated_x

or something. I don't see that as a real justification for the feature (heck, I don't see the justification for partial properties, given that source generators have been getting along without partial properties for 22 years).

Sure. But they're not showing much restraint. They're as capable of making mistakes as the rest of us.

There are different philosophies of programming language design, Consider Go -- which is a widely used language despite being newm and is very popular with startups. I'd consider it to be "reactionary conservative" in its design philosophy (no meta-programming at all, no exceptions, guaranteed to give you carpel tunnel from all the typing). Or Java - a far more popular language than C# - which again has chosen to add features slowly, and with restraint.

I don't think those are better design philosophies than C#'s "everything in the kitchen sink". But there has to be a middle ground.

I'd say it is FAR, FAR better argument than saving keystrokes. "Users need to type less" is a tiny, tiny advantage weighed against complexity, readability, debuggability, mental energy required to understand a piece of code, etc. In isolation, any one of the new features is fine, but there have been dozens of additions to the C# spec in the last few years. It's time for them to pump the brakes.

 

As far as I can remember, recently added features (especially pattern matching) are requested by the functional programming community. The on-comming features related to functional, for example roles and extensions atm, and possibly higher kinded polymorphism in the future, would introduce a heavy layer of meta programming into the language. They wouldn't make sense to us, but they are there to serve another community.

 

This is getting off topic and I can’t help but feel partially responsible.

If we get them, that’s what rust editions would be for. If it’s opt-in I don’t see the problem.

Please don’t take this as an argument against your points (they valid), I don’t want to trigger a discussion on editions now, I just hope that they can help satisfy both parties.

 

Ok, we all can see now that you have no idea how many features in C# work. Take a look at Sharplab.io: https://sharplab.io/#v2:EYLgZgpghgL...AMowCDK6YZoO4vrOZhbWgZmOBh4uee6ePn4BYaGCwUA==

You....do know that Roslyn Source Generators have been around for only 2 years now, right?

Yeah i don't know about you, but more expressive code that takes less time to fully comprehend because you inherently know what it does because you learned it helps me a lot more in all your points than having to read longer code that is always individualized but ultimately tries to achieve the same thing as 100 other code pieces.

You are not being forced to use any of these features. If you don't like them....don't use them and do it manually. Only potential downside is your productivity being affected.
I personally hope C# will eventually get at least 10 times as many features as we currently have. There's certainly enough possibilities to add this amount of *valuable* features into the language.

 

IMO, features like the one being discussed (semi-auto properties) aren't really about typing less, they're about reducing cognitive overhead when reading code. They take common patterns that people use all the time and give them a standard, consistent, language-level syntax. When I'm reading code and I see that syntax, it's a signal to my brain that this piece of code uses a pattern that I am familiar with and fully understand.

In the present day, if I'm reading C# code and I see a property that implements the "backing field" pattern, I can be pretty sure it's that pattern right away, but I have to actually go and check to be certain. Is the apparent backing field actually a field, or is it another property? If the property is instance, is the backing field also instance, or is it static? Is it the same type as this property, or is there some implicit type conversion going on that could have side effects? And, most insidiously, is the backing field only used by this property, or does other code modify it at some point?

The cognitive overhead of verifying all these things is small but nonzero, and over years of working with C# code, it adds up. In contrast, if I see a semi-auto property, I'll know with ABSOLUTE CERTAINTY that it implements the "backing field" pattern in the standard way. I won't need to worry about possible nonstandard implementations of the pattern; I can reserve that cognitive capacity for understanding the code that's actually important.

Another benefit is that it reduces vectors for screwups. It's impossible to implement the pattern wrong when writing the code, because the language implements it for you; and when writing other code, it's impossible to accidentally use the backing field when you meant to use the property.

I've used semi-auto properties as a case study in this reply, but I think the same points apply to most of the high-level abstraction features the C# team has added in recent years (and is planning to add in the years to come).

 

Holy fk kid, why are you every time super toxic whenever I see you trying to make an argument XD
C# isn't technically the first language to invent Source Generators and I think that's what he meant.

Anyways... I personally find that unless IDEs have support for these *new* features nobodies gonna know about them... Like let's be honest how did we find about null-coalescing operator?

I don't hate these features and I actually agree, they definitely help readability, but they also force "best-practices" on newcomers to C#, while most of the time it doesn't even matter if they do a simple null check and throw or use the null-coalescing operator to throw automagically!

If C# decides to remove old features (which seems to be the current direction), then that will also be a huge positive as many frameworks will be FORCED to renew old APIs, which keeps things fresh (*cough* *cough* Unity 5 Monobehaviour References).

This minimizes these "best-practices" so that there is one way and only one to do smth.
For example, why wouldn't one use file-scoped namespaces? To have multiple namespaces in one file? A very bad idea!

 

I'll only add 1 phrase to the current topic: "Implicitness is NOT expressiveness"

 

That's actually extremely easy to answer. Because I can not stand thick-headed people, willfully ignorant people, or people unwilling to learn new things, and it just so happens that one of those groups happens to always chime in and starts arguing about....what? nothing of substance. (If you want an example to a 1:1 similar occurrence not involving me, just look into the most recent forum post discussing the possibility of Unity providing more open source access.)
Thank you.
People, .....be more open to change.

Otherwise agree with the rest of your points. :thumbsup:

 

There is no need to be rude. I understand the feature perfectly well.

Windows Forms was released in 2002. It generated code containing properties with backing fields.

Sure. And that's a perfectly fine argument if you already know the language, and are writing code alone, instead of in a team environment.

The potential downsides come when you're...

• learning for the first time and see an overwhelming number of features.
• reading/debugging someone else's code
• debugging your OWN code with a ton of other stuff to keep track of
  
• onboarding a new team member who knows Java/JavaScript/Python, but isn't familiar with C#
  
• you hire a contractor and they follow some different coding standards and you have some giant mess of code to clean up
• you're not very familiar with the language but there's an interesting library you want to look at on GitHub or something and you want to translate the algorithm (for a recent gamedev example, I just translated this function from C++ to C# -- it relies extremely heavily on unwritten/implicit features of C++ and the way iterators work; it's almost impossible to do bug-free without knowing the STL, despite the syntax itself being obviously familiar, and the intent being fairly clear)
  
• find a bug in an open source project and want to submit of pull request.
  
• you're the curator of an open source project and need to review incoming pull requests.
• ...

These are not theoretical/what-if questions. They cost the software industry, collectively, billions of moneys.

You say the cognitive overhead of writing backing fields is nonzero, but the cognitive overhead of knowing the "field" as a contextual keyword is also nonzero. One of these downsides is more "frontloaded" than the other. Eg if you're learning C# for the first time, maybe coming from a JavaScript/C++/Java background, the "field" thing is not obvious, while backing properties are obvious.

Explicit is clearer than implicit. It's not always *better*, but it's certainly clearer.

Sure, I can appreciate that it reduces the potential for typos or missed copy-pastes.

Again, though, it comes down to the idea that while all of these features can be taken to be positives when looked at in isolation, or when given a bug report/slide deck with motivating examples, when you toss them all in, you get a mess that's tricky to learn, tricky to debug, and inconsistent between different codebases. If you've ever worked with C++ -- especially the newer versions of C++ -- you'll know how implicit and inconsistent syntax and high cognitive overload lead to bugs. Or... ever tried to read someone's Perl script? Perl became a joke because of how many keystroke-saving features were thrown in.

The value of each addition should be weighed against not just itself, but the complexity, consistency, discoverability, and readability of the language as a whole. The C# team used to do that and for about 15 years, it evolved slowly to be "kinda like Java but a bit better". Their philosophy recently has shifted rather dramatically towards introducing complexity, perhaps in some arms race with Python?

 

It is times like these where I sit back and get my popcorn.

Ladies, if it’s opt-in then there is nothing to talk about. You’re not gonna convince the other, and only making fools out of yourself.

Go outside. It’s Sunday.

 

I know it's kind of a waste to argue this point, but... this comes off as so self-centered. It has nothing to do with being "unwilling to learn" personally; it has to do with being willing and supportive of other people - especially new users - learning, and making their learning experience easier.

 

Now i have a completely different approach to this. I am still for allowing people to get into new things easily, but a programming language is ultimately there to empower the seasoned developer. So as long as there are transparent, easy to reach documentation and samples for every feature out there, it doesn't matter how many new features are added, because even new people can learn them eventually, and if they don't, that's solely on them.

 

I do somewhat agree, but only if you take the code out of an IDE. Many things, *especially* language keywords (like 'field' would be) have distinct colored syntax, and the limited context in which the keyword is used is enough to quickly grasp it's use. To take your other-code-bases look into account, i've seen repository code where people but the properties on the top of the class and the backing fields after all the methods all the way at the bottom of the class. I'd certainly say that cognitive load is pretty much uncomparable.

I know I can be brash, but I don't mean to be downright rude.
Apologies for that.

 

Okay guys we've actually been discussing this for a long time and it is *HELLA* off-topic.
Wanna create a new thread?

 

Here you go boys!
https://forum.unity.com/threads/is-...ed-or-syntactically-incomprehensible.1431664/

Oh and also... new syntax XD

 

I was wondering, can we expect UnityEngine.Debug and Assertions to get updated with new C# features in mind?
Specifically CallerArgumentExpression and this funny string building stuff Nick Chapsas did review on ('cause he's everywhere!)
I would love if using Debug.Log and/or Assertions wasn't such a hit on the framerate because of how strings in C# work. Same goes for Debug.Log version that could maybe have ReadOnlySpan<char> overload? In case user is using NativeText or something alike

Sorry if this question was already asked, this thread got too long for me to remember all of it....

 

I don't think this specifically has been asked before, but iirc they said they wanted to update / add more performance oriented overloads to Unity's API.

Yes, those are indeed very awesome features and i think we would all like the Unity team to make the Unity API even better. :thumbsup:
You've got our support, Unity. Even if it's just on a moral basis at the moment. Ganbare! (頑張れ)

 

When tho? Any version we could play with this already?

 

They will inform us when it’s ready, but it’s not in any of the 2023.x release versions, it will be somewhere in 2024.x (most likely, nothing guaranteed because not confirmed).

 

The Avalonia maintainers were successful in running an Avalonia app with NativeAOT on Android and they're willing to contribute the patches needed for it back into the runtime repo, which means that with .Net 8 NativeAOT will support the main targets for Unity (Desktops, Mobiles and Consoles) without a need for separate ports for them.

 

It can also already compile into WASM to run in browsers and node: https://devblogs.microsoft.com/dotnet/use-net-7-from-any-javascript-app-in-net-7/ I'm utilizing this to share C# libs between a Unity plugin and associated VS Code extension and standalone Web-editor; works quite well.

Though I'm not sure about consoles. Don't think .NET will ever support them, as the SDKs/compilers are vendor-locked. And it's unlikely anyone will bother building and maintaining a port under the same NDA terms (at least non-commercially).

 

Hi @JoshPeterson

Do we able to use WASI sandbox when unity migrate to .Net 8 ?
https://twitter.com/stevensanderson/status/1658845798212202496

 

The blog post you mentioned is using Mono AOT, not NativeAOT to compile C# to WASM. WASM support for NativeAOT is being worked on but it's currently experimental and is missing a lot of base runtime features so it's not really production ready.

As for console support, there are already unofficial (but endorsed by the developers) ports for Xbox, PlayStation and Nintendo Switch that are being shared under the NDA terms.

 

Does this mean that 2023.2 will have CoreCLR support for Windows ARM64, or is this a mistake?

On another note, support for NativeAOT for Android is being currently merged into the runtime repo.

 

Why wouldn't they support it? Honestly this could be really cool, especially because Unity is made to run on ARM-based hardware (iPhones, etc...) and is pretty performant on them too!

 

I wasn't expecting Unity to land CoreCLR on any platforms already in 2023.2, thought we'd have to wait for 2024.1 at least.

 

This too looks interesting:

 

No, that's build system.

 

Given the amount of work to move to CoreCLR why not consider supporting C++ since the engine is already written in C++.

 

Interesting decision to make - core engine code i would've thought would benefit from performance of C++ rather than opting for C#. Or is C++ just used in performance critical areas?

 

Not really their decision… I think C# has been the main language since 2013? In any case it was made years ago and it was when Unity was less performance-critical.

Nowadays though they have the Burst compiler and Job system which are much more performance focussed than C++ on its own, not to mention that CoreCLR comes with a lot of free performance to close the gap to C++, and there’s always the literal C++ converter IL2CPP.

That’s not to say there would be no benefit, but Unity would be much harder to pickup for newbies. I know I wouldn’t have as a 14-year-old. So it’s pro’s and con’s, but I think there’s other ways to gain performance (and hopefully CoreCLR will be one of them).