Microsoft is Breaking Your Code in C# 13

[@JackTheSpades]

You mean to tell me that we've been writing private fields like this for years because of the fear that some people could complain about having to rename some their variables? Get these breaking changes out there already!

[@therealpeter2267]

I wish we could just have a c# branch where everything is constantly wrecked that needs wrecking and we would get these features maybe like every 3 major c# versions.

[@rapzid3536]

The idea of auto-migrating code bases to account for breaking changes is relatively new. Golang blazed a path here; they had gofmt and "go test" built into the tooling from the early days. That, along with the ubiquity of OSS projects on GitHub, allowed them to confidently introduce breaking changes and automate testing the migrations against a large percentage the ecosystems projects.

[@carldaniel6510]

Personally, I'd prefer that they just make the breaking change and make me change my code rather than adding subtle features. Pain due to a breaking change is transient. Pain due to a subtle feature is eternal. All that said, this is a nice and long overdue feature and I'll definitely make use of it.

[@robertnull]

Finally some green light for breaking changes in C#! Maybe we can have nice things in the future after all instead of maintainting legacy forever :)

[@azoofahmed]

I think it's time for c#++

[@jfftck]

​@azoofahmed Maybe it should be ++C#, since it isn't holding on to the previous iteration?

[@AndrewLaw87]

This is a fair break. It only takes one harmless PR to replace all "field" with "@field" before upgrading to c# 13.

[@qj0n]

especially if they provide you with automation to do it...

[@PaperPilz]

Some more nice things to note: When you upgrade to dotnet 9 but are still on C# 12, you will get compiler warnings for the spots where the break occurs. Also, the keyword is scoped to properties only, which I think is very nice as well!

[@alexclark6777]

I respect their decision and understand why this is not an easy choice to take. C#'s backwards compatibility has long been one of its strengths, and making sweeping changes to new versions of the language that break older releases would have been detrimental to its success (for proof, look at Scala). I'm excited that someone on the language team has decided "ok we can do these things as long as we're careful and there's a simple upgrade path".

[@aborum75]

Can definitely commend the C# team for taking the right route on this one, and with that hopefully introducing additional changes with greater confidence in the future.

[@raykutan]

FINALLY! I've been waiting for this keyword for so long

[@shanehebert396]

I've wondered about that for ages... It's always tedious to not be able to use an automatic property because you have to do something other than just set or get it because you have to put a little logic in there.

[@vladgonzaleza8774]

am i the only one who always hears "Hello I'm naked" when he says "Hello I'm Nick"?

[@8BitsPerPlay]

shh it took months to unhear it the first time.

[@dmytrohryshyn]

I think it is nice addition. It will help reduce a boiler plate in WPF applications where you almost always must to have backing filed and fire on property change event in the setter.

[@promant6458]

00:09 Well, technically, it's not a new keyword, because 'field' was already present in the language as an attribute target for properties, e.g. [field: SomeAttribute] public int Age { get; }

[@nickchapsas]

ACKCHOUALI

[@promant6458]

​@@nickchapsas :)

[@8BitsPerPlay]

This is something a lot of Unity developers uses. They use [field:SerializeField] private int Age {get;set;} Unity doesn't show non serialized fields in the inspector so to get around it you use the field keyword with the SerializeField attribute to reveal the properties in the inspector.

[@LittleRainGames]

Ive been working on my own C# features and created the __bakfield operator/expression. You pass it a property just like nameof and allows you to read or write to the backing field. Usually this would be a worthless feature because you always can access the backing field of an operator, but the properties the backing field works on is a special type of property, that generates accessor methods with special functionality.

[@cubbucca]

I expected this to already be a thing that i just hadn't worked out. I'll be using this straight away.

[@TehKarmalizer]

Meh. It reduces a little boilerplate by hiding explicit code behind sugar. I don’t really care overmuch because I don’t think I’ve ever named any field “field”, but it’s all just an abstraction over the getter/setter model that doesn’t really add anything new. I never balked at adding explicit backing fields when necessary.

[@yeica]

There were situations where I needed this so bad. This has to be one of the greatest features added to c#

[@JaimeWyant]

What website shows that IL code?

[@alexanderkvenvolden4067]

I wonder why they aren't keeping compability with the "var" method. The var feature is inactive if there's a variable named "var." Seems like the field feature can also be inactive if there's a field named "field." This would be easier to do than var compatibility because it wouldn't include local variables, and it's actually somewhat reasonable that there may be fields named "field" on some smaller classes.

[@uwose]

I've always been missing a variable whose scope is only inside the property. This is the encapsulation I searched for when I started using properties!

[@ernstgreiner5927]

Since auto props i use mostly oneliner, so for me it's not that impact, but I like it because it means one/two lines less per property if you need it. So i think the breaking changes thing isn't that dramatic in this case, just make a rename-refactoring of the code before switching to C# 13.

[@rupenanjaria]

Great video, question: in that case why your code doesn't break at 6:34? Shouldn't field be alerted as reserved word and C# compiler should ask to convert @field?

[@onman999]

Does anybody know what IDE / plugin Nick is using to see that lower level code? I'm refering to that dropdown list 'Results with options like 'Decompile C#', "IL' which is shown al 2:07.

[@jongeduard]

Oh, I am not worried about the breaking naming conflict, I am used to this kind of thing. I'm already used to the pain of working with on project in which an important database table has the name "Object" in it, and therefore that name also has to be represented in the C# code, in a workaround way, since Object also already the base class of everything. Amazing. 🤦‍♂🤣

[@Tsunami14]

Certainly not an easy decision to make, but sometimes you need to hresk things in the name of progress. Otherwise, we'd still be marking up web pages for IE6.

[@martinprohn2433]

So, I assume you could just use LangVersion 12 to circumvent this, right? (Not that I would have why reason to do so, I'm just curious)

[@JaredParsons]

That is correct. LangVersion 12 and earlier will have the existing binding behavior. True for pretty much all features.

[@trader548]

C# 13, unlucky for some 😉

[@privatesocialhandle]

Your comment was made "13h ago" about "unlucky 13" and got "13 likes" .......

[@emmanueladebiyi2109]

Thanks

[@alexanderkvenvolden4067]

"If that sounds familiar..." I tried to use it last night. I thought it was added already.

[@holygoe]

Hello Nick! Thank you for the videos that you create. However, there doesn't seem to be an issue here. In fact, I have been waiting for this feature in the language for a long time :) Of course, I can't say exactly how this will be implemented, but it looks like it should work as follows: If you already have a defined 'field', it makes sense to use it. Otherwise, it would be used as a keyword :)

[@rhimael]

I would like to see something like setter parameters that automatic changes the value type, something like: public int Prop { get; set(string) => field = int.Parse(value); set(MyObj) => field = value.ToInt(); } So we can stop creating more lines just for implicit casting, i don't know if this is even possible

[@ShadowMasterT]

I can see this becoming a thing once they introduce discriminated unions, as you can enforce proper typing and use pattern matching syntax… But honestly, it feels risky without it. Even your example has to explicitly declare supported types. Might as well just define your own custom type that stores the value as one type and declares its supported implicit casts and achieve this behavior with a fully automatic property IMO.

[@rhimael]

@@ShadowMasterT I understand your point and I agree, but to an extent, I think that creating a classic CustomType just for a simple use case of implicit cast is too much, i know that we can use the constructor to receive different types, etc, but the point is also to take full advantages over the {} initializer. I would also like to the compiler do some more syntax sugar for simpler things (which is something that contradicts the way I dislike the "too many ways to do the same thing" in c#)

[@fusedqyou]

I think this goes beyond the scope of what properties should be and more what methods should do. And luckily this already happens for methods. Either way the different types are nice, however. Especially when you support different types and want to store them under a general object type.

[@ShadowMasterT]

@@rhimael It’s definitely a lot, and screams “boilerplate”, but as soon as you want to reuse that logic - moving it to the type level is the correct thing to do. But it’s still essentially just implementing a discriminated union, minus the string parsing aspect that goes beyond that simple logic - and as soon as you want to make more than one - that’s when this manual solution defeats its purpose by becoming inconvenient. And I agree with you that this is where language support could come in handy. Still, my point stands that the compiler and the language need some contract in order to let this happen, and discriminated unions are probably the right solution, so mimicking it is the way to go for now IMO.

[@rhimael]

@@fusedqyou for sure, but get and set are "hidden" methods already, it would be almost like generating overloads for them, no?

[@bladbimer]

this is interesting, I noticed many time the need to use the backing field and maybe this could help creating better library that will minimize the need of implementing logic inside the get set ourselves.

[@owns3]

I really want this feature. This would've been so nice when doing properties in WPF back in the day!

[@andraslacatos5832]

A couple videos earlier we saw Nick in VS Code and Visual Studio, now in sharplab, what is coming? Emacs? Vim? Microsoft word?

[@Daniel15au]

He uses Jetbrains Rider in a lot of his videos too. It's also what I use for C# dev on Linux.

[@andraslacatos5832]

@@Daniel15au that's why it is strange to see him in anything other than Rider

[@grandeau3802]

Great. Another feature that saves you 1 line, but is not intuitive, has to be explicitly known and raises the learn curve further for newbies.

[@qj0n]

yes and no. C# properties are indeed extremely complex when it comes to all variations of syntax. But in this case it's not that bad. Firstly, it allows to get completely rid of backing field pattern, so after some transitional period, the variety of properties will be back to the same Also, this is not a frequent use case in many areas of development. Sure, you'll use it often if you develop against some MVVM framework, but I wouldn't bother teaching it to soon-to-be web developer Also, this actually prevents a lot of bugs in viewModel when you set the field instead of property...

[@qj0n]

I don't follow C# usage outside of .NET, but looking at .NET release cycle I guess it'd be possible to release such breaking changes in following manner: Add warning to every broken code usage withing LTS release. Rosylyn should have code fix implemented to quickly fix all the warnings in whole code. Break the change with next short-time support release so that people blocked with this change have more time to adapt as they are on LTS I guess this way, they can release breaking changes to .NET devs, at least if fix can be applied automatically

[@sunefred]

Does anyone know how they solved this problem when "var" was added in C# 3.0?

[@qj0n]

similarly to creating the "_" write-only variable. If you have any "var" type defined in the scope, it takes precedence. You still can write class var { }; var x = new(); and the 'x' variable will be of type 'var' I guess there would be some issues with that in this case. E.g. when you define a 'field' variable inside of getter and not setter, you would have two different meanings of the `field` word in one property

[@sunefred]

@@qj0n Thanks for the insight!

[@Droidrevenge]

What about escaping the name of the backing field and not the field is already in place?

[@louisfrancisco2171]

C# escaping keywords is already a thing. Escaping something to make it a keyword would be unusual.

[@petewarner1077]

This is going to cause nightmares for my new open-source project "Fieldy", a system that manages form-fields for students studying in the field of electromagnetic fields on sports fields.

[@user-rz1hv]

lol

[@xaberue]

Wow, we have a project where one of the main entities is called Field, so... the project is plenty of field variables everywhere, this upgrade will be fun....

[@billy65bob]

That would've been so nice for OnPropertyChanged. Kind of pointless now, since the MVVMToolkit just source generates that bother... 5:50 I'm not worried about the nomenclature, you could already annotate it with things like [field:*Attribute], so using the same keyword is just consistent. I do hope they add a warning (or preferably an error) about fields named "field"; in my experience they're usually either named _field or theField, so it should be moot.

[@fifty-plus]

I can't remember the last time I used a backing field in a property. I'm guessing it would have to be soon after auto-properties were introduced.

[@ConductiveFoam]

In the data binding targets for WPF you have backing fields everywhere as you need to `NotifyPropertyChanged` in setters, so I for one am looking forward to the feature. But yeah, not everyone will have a use for it.

[@lalithprasadsrigiriraju]

Hey Nick, what is the web app you are using to write code? Thanks.

[@nickchapsas]

Sharplab.io

[@Rovsau]

Would use of the 'this' keyword avoid code breaking in such cases?

[@daniilpalii6743]

No

[@brenthompson2]

I'd think it would. 'Get => this.field * 2' seems like it would clearly get around the ambiguity

[@daniilpalii6743]

​@@brenthompson2 "this" keyword is not required. If code now has something like "int field; int Field => field * 2;" than code still will need be modified before update. It should become "int @field; int Field => @field * 2;" or "int field; int Field => this.field * 2;". The second option makes "this" keyword required, which is more breaking change than introducing new keyword

[@lordmetzgermeister]

The C# dev team announced some time ago they'd include breaking changes, I guess this is it.

[@aweklin]

Yeah! I saw this during MSBuild2024.

[@obinnaokafor6252]

Visual Studio has Copilot AI rename. Just select the variable name and ask the AI to give you a better name and replace all. Some people like to complain a lot. I would like the C# team to remove legacy things and make some breaking changes in order to move forward and incorporate newer features.

[@marcotroster8247]

Why don't they reserve some silly naming convention like prefixing with 10 underscores for the generated fields and break the code that doesn't conform? Nobody should ever surface such a variable through an interface anyways.

[@maksymkyian4920]

Great feature, especially for ViewModels in WPF :)

[@ConductiveFoam]

I was writing that in another comment! Really looking forward to it. I have written a source generator for simple getters and setters, but this will be really nice

[@KarmCraft]

Wouldn't the keyword "backing" have been better? I guess it's a little less used of a word and communicates the concept better than the word "field"

[@user-rz1hv]

not at all, look at Kotlin, they have field keyword too for the same purpose

[@Petoj87]

I wish they had this mindset when they added the DateOnly type.. but I guess that was a harder thing to solve..

[@ksanchez8095]

I think they should use the @ notation for their own field and leave existing fields alone.

[@disinfect777]

why not just make it a lambda and call the var whatever you want. what am i missing? get x => x * 2; set x => x;

[@psyarhei]

I think C# code in right panel is not just a lowered C# code, but decompiled

[@theMagos]

Any chance we could get a syntax for accessing the backing field from outside the property (but still within the class), you know, for the sense of micro-performance-optimization? Like: field(Number) = 123;

[@qj0n]

I'd say the whole idea of this feature is exactly to avoid it and encapsulate the field withing the property. Just like with private fields, you can access them via reflection, here you actually have autogenerated field, so you can use it. Checking in sharplab, it translated public int x { get => field ; set => field = value; } into: private int k__BackingField; public int x { get { return k__BackingField; } set { k__BackingField = value; } }

[@louisfrancisco2171]

You shouldn't need to optimize anything. Any access to an auto-property should already be inlined.

[@theMagos]

@@louisfrancisco2171 It's not. All access is through the get/set functions, not the backing field. Check the lowered code.

[@louisfrancisco2171]

@@theMagos The lowered code is not the jitted code. The JIT compiler replaces calls to small methods by the code of those methods, making the access to an auto-property exactly as fast as a direct access to the backing field.

[@roach1628]

Is this attempt 3 or 4 for semi-auto properties? If they actually make it into c# 13 I will eat my keyboard (and be happy because they were finally added - I had given up hope).

[@makescode]

It would doubtless break much more stuff, but I am kinda sad that the set accessor could not be rendered as a lambda that returns the new value of the property. In other words, "set => value;" would be equivalent to just "set;". But no, someone had to go and make the "void" lambda have the same syntax as a value-returning lambda.

[@damiengilbert7055]

I'm all for breaking changes. Sure backwards compatibility is really nice, but if it is stopping progression then it's time to cut ties and keep moving forward. The future waits for no one, but especially technology and science.

[@efrenb5]

This is a great compromise. Having to manually create the backing field is such a nuisance, unless you want to make it volatile. Nevertheless, I wouldn't cry if my code breaks because of this. Very easy fix.

[@ojcieccc]

Why didn't they name it @field?

[@louisfrancisco2171]

Because escaping a keyword to make it an identifier is already a thing in C#. Escaping an identifier to make it a keyword isn't.

[@z_prospective160]

new keyword.. easy fix.. renaming variables is a relatively simple thing to do for any codebase. Not too bad. I think the feature is long overdue personally.

[@TheTigerus]

that's M$ recommends using underscores :)

It's not a probem if you are used to prefix the fields with an underscore.

[@SpeedyMechnic]

Well, I just wrote something today with field as the property. yeah.

[@billy65bob]

I hope you named your backing field '_field' and not 'field' like a good C# developer :^)

[@ArlenKeshabyan]

I believe, the "this" keyword could be used instead of "field". Thus, no breaking change is introduced...

[@louisfrancisco2171]

And how would the compiler know you want to access the backup field and not the object instance ?

[@ArlenKeshabyan]

@@louisfrancisco2171 good point :)

[@Grumpicles]

I want to know what % of the community actually asked for this feature. We started with verbose peoperties and backing fields that gave us full control. Then we went to the.. what do you call them? The one line properties with a hidden backing field which has been great. Why do we need this?! Does the language not already have ways to solve whatever needs to be achieved??

[@user-rz1hv]

no, Kotlin has this keyword too

[@ChristianHowell]

Self-documenting code means you use a recognizable variable name for ease of reading...

[@RandallEike]

Whohoo! Finally!

[@Naton]

I wish for option monad

I love Kotlin because it has this feature as the beginning. (or at least, when I started working with Kotlin, it had had this feature already). I want C# to have the same, but it's pretty painful because can break the existing code. Also the keyword "it", it's the default lambda parameter, on Kotlin, it's amazing.

[@MichaelBattaglia]

I think that this feature requires field testing...

[@oscareriksson9414]

I don't get it.. if you want to access a field from outside the class. There is a keyword already. Public

[@dangg44]

Amazing feature, but why did they realize only in 2024 that this should have been introduced?

[@NawfalHasan]

6:50 lol 😂

[@Kingside88]

yeah without flimmering

[@_OsamaAmir]

reupload?

[@verzivull]

fixed

[@Faygris]

If you've named your fields "field" regularly, I would argue your code should need a bit of refactoring, anyway 😏

[@NoName-1337]

Works well now. See no artefacts anymore.

[@IllidanS4]

I do not envy the C# team having to decide on this one, but I also regret the outcome. Over the years I have started to value languages more and more based on the longevity of the code you write in them, and while this does not matter that much for .NET where you can easily combine projects each using a different C# version since it is all CIL under the hood, it is still taking the wrong direction. Yes, there can be tooling to help you update old code. But it is the step in a list that you will always have to go through when incorporating old code. If you have a type named "var" or "await" or a member named "field" and you reference it without @, it should cause a warning, and this warning should be treated as an error in new projects, but I don't see why I should be forced to subscribe to this when all I want are new C# 13 features. I'd take any inconvenience like this to know that my code can be run in 50 years from now.

[@Dr-Zed]

go cry some more

[@MC_DarkMaster]

Spoiler: It won't come in C# 13 :D

[@tridy7893]

It is kind of a clickbait title, saying that "IS" breaking code, which would mean everyone's code, which is way far from the truth, if any, actually.

[@jimread2354]

Yeah, this might take dozens of people seconds to rectify in their code. The horror! That said, it's kind of a meh feature if you ask me. I don't find it that galling to crank out two more words to define a variable that has a real name. Not sure i'd even use this given the opportunity because it seems a little like "int x;"

[@obiwanjacobi]

Seems hardly worth the trouble. As a lot of the later features it is syntax sugar we can do without. Adding a backing field manually is not a drag, that's called programming. If you don't like to type you should go do something else. And with all these alternate ways of doing the same thing I don't think C# is getting better. Not unless they will enable me to disallow certain (older) feature and/or syntax constructs. Look at C++ (if you dare) if you want an example of how not to evolve a language.

[@kobor42]

This is stupid. Why not "Number.value" inside the get Number property?

[@trumpetbob15]

Seems like they purposely made things harder on themselves rather than thinking logically. If this is representing a backing field, why not just name it "backing"? If it is going to break code anyway, limit the damage. Something tells me if we counted all the code that uses the word backing, it would be far, far less than that which uses field given how many different definitions the word field has, including ones not mentioned such as a database field.

[@louisfrancisco2171]

It's a matter of opinion perhaps, but for me, if something is named "backing", then it should be a boolean. If it's not, then you should not use an adjective or participle.

[@bitman_agent67]

As a former MSFT employee, I am not afraid to say the quiet part out loud. Was the PM just out of ideas for design goals, and this BS floated to the top? I want to know what got cut for this feature to live. This is a solution looking for a problem. PM: "Devs get tired of naming member variables, so we must save them from this incredible time waster as part of our Increase Productivity goal." Smart Dev: "What if there is more than one member variable in the class, what will they name those? FieldEx?" PM: "That is a non-goal. We are only solving the scenario for classes with one member variable. So how many dev days will this take?" Geezus Fkn Christ!!! Oh wait I forgot, the language is now open-source. So some noob created a PR for this because he saw it in another language. The maintainer accidentally merged it; now it is a thing. Hope 13 is not LTS.

[@mekowgli]

I think you're assuming that "field" is an actual field in the scope of the class. It's not. It's dynamic and points to the backing field of the property you're in. In property A it'll point to _a and in property B it'll point to _b. The keyword "field" only has a special meaning inside getters and setters. Same as "value" in a setter. What I wonder is why they couldn't simply use a name for the keyword that's less likely to cause conflicts. Like "autobackfield" or whatever.

[@andrewshirley9240]

The "former" is doing a lot of work here. This issue isn't solving the "difficulty" of "naming variables." It's an encapsulation problem. Right now if you have special setter logic, there is NO way to enforce within a class that the setter with that logic is actually used. Manual backing fields are class-scoped and can be manipulated directly. This can, and DOES, cause bugs. What this does is allow you to have a property-scoped variable (provided the backing field is the same type as the property it represents), which is a huge step up. This probably could've been implemented as a "field [Type] [name]" keyword defined within the property before the getter/setter and been even more flexible while solving the same problem, but that solution can be easily extended from the current iteration so I'm not mad at this change.

[@qj0n]

@@andrewshirley9240 Exactly! That's a very frequent case in WPF ViewModels, which tend to be quite large and someone somewhere updates the field instead of property resulting in event not emmited...

[@Tony-dp1rl]

What a stupid way of fixing that problem.

[@chudchadanstud]

Wow! More bloat!

[@zachemny]

IMO, it's a highly overrated and controversial feature, there was no real need to introduce breaking changes just for it. Similar feature "Property-scoped fields" are much more flexible and doesn't break anything. You just define field name and type as usual, but inside the property, so no "field" keyword is required.

[@pzodeosrs]

That's a decent idea. Though you could argue that 'value' has the same issue (in terms of naming limitations) as 'field' would, so you should _really_ define the "parameter" as well. Of course, 'value' has existed since forever, so it's not breaking anything.

[@zachemny]

@@pzodeosrs The problem is not that in some rare cases it breaks code. But because it doesn't add significant value from similar proposed and more flexible and less problematic feature, aside from removing 1 line of code per property.

[@Dr-Zed]

unsubscribed and disliked for clickbait

[@user-tk2jy8xr8b]

The properties were initially a bad design, now the consequences of the decision to introduce them strike back again and again as cumbersome patches over patches

[@hcbrl]

Love your videos but lately is like 80% ad, 20% content, a bit annoying

[@abdullahm.3363]

Always fear mongering 😡

[@cverde1234]

this.field is probably clearer than @field