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!

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.

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 :)

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

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".

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!

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.

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

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.

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

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; }

C# 13, unlucky for some 😉

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

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.

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.

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.

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.

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.

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!

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)

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.

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.

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

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.

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

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

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"

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. 🤦‍♂🤣

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?

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.

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.

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

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....

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

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.

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

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.

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 :)

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.

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.

What website shows that IL code?

Great feature, especially for ViewModels in WPF :)

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;

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.

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??

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

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.

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

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.

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

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.

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

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

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

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

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).

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

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

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

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

yeah without flimmering

that's M$ recommends using underscores :)

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

6:50 lol 😂

This breaks no reasonable code and the fix is easy. C# should absolutely make these breaks even though I don’t care for this very limited feature much. An odd place to take a breaking change. I want nullability to make it to the runtime.

Thanks

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;"

I think that this feature requires field testing...

Why didn't they name it @field?

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;

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.

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.

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

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

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

Works well now. See no artefacts anymore.

I wish for option monad

Whohoo! Finally!

reupload?

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.

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.

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.

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

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

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.

What a stupid way of fixing that problem.

Wow! More bloat!

unsubscribed and disliked for clickbait

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.

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

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

Always fear mongering 😡

this.field is probably clearer than @field