C# 9 Language Features

on today's on.net show we're going to be talking with jared parsons about c sharp nine we're going to be talking about records they let you write so much less code if that's interesting to you stick [Music] around [Music] [Applause] welcome to another episode of the on.net show today we're going to be talking with jared parsons about c sharp nine welcome jared hey thanks for having me rich yeah so uh c sharp that's kind of what you do right yep uh i'm the dev lead on the c-sharp compiler team i've been doing that i've been working in languages at microsoft for a little over 15 years now and on the c sharp uh primary team for about last six or seven years nice um so c sharp nine that's the thing like it's going to ship with done five-o later this year yep yep that's going to ship apart.net 5 and 16.8 to visual studio uh yes yes cool so we're going to kind of go through the entire language or just like uh some specific features uh today we're gonna focus on a little bit of a subset of features mostly uh records and knit properties and top level statements is kind of what we're gonna be going through today right so would you say how would you characterize c sharp nine from like uh you know super small release like massively game changing uh i would say it's kind of a medium style release which makes a bit of sense given that when we released c sharp eight that included nullability which was on the massive end of feature scale and so part of c sharp nine is both doing some more work on nullability but also catching up on a lot of stuff that didn't quite make it into c sharp eight okay that makes sense okay how do we get started all right so as i said today i really want to kind of talk a bit about records um and so records are a new way in c sharp of letting you define class types and particularly these are meant for types which really act as values instead of traditional objects and by that by traditional objects i mean in university you're kind of taught that the job of types is to encapsulate state and essentially hide it from your consumers they should really only indirectly access it via methods and properties um in theory you should be able to swap out all your state and the consumer should be kind of none the wiser value style objects are kind of the opposite of this their behavior is really defined by their state for instance like if you think about like a point like index and y the entire object is defined by that state and those type of objects generally kind of eschew encapsulation instead they just say like hey here's my x and here's my y like access it all you want um and these are fairly common types in programming in general and dotnet as well i mean if you think about any kind of json programming you've done in c sharp you've stubbed out a whole bunch of json values to go in and out of your serializer and those are effectively all like value style objects um but in addition to kind of exposing their state these these objects tend to want kind of a very very fairly common set of behaviors they want to have equality so the ability to appoint two points for the same x and y's like they should be equal uh they want to have deconstruction they want to work with c sharp pattern matching and possibly they want to participate in immutability and records come about because adding defining these types with these behaviors in c sharp i mean it's very doable it's a small amount of code um that can be but it's that code is quite boilerplate and it's basically the exact same for every one of these objects and while it's cheap on kind of an individual object if you look at the totality of your program it really starts to add up like if you think of an asp.net application you're using a lot of these value style objects in all of your json definitions your rest apis your ef models a lot of the helper types you use for your razer views and this just this small amount of work on the individual scale just adds up a ton on the scale of a program and i think kind of the best way to demonstrate like the power they provide is kind of start building up a sample from the point of view of a c-sharp eight developer and kind of getting a sense of the work involved to make this happen so what we're going to do here is we're going to start we're going to avoid watching jared do a ton of typing we're going to start with a very simple person type and what we're going to do here is say that hey i have a class person um and it has first name the last name and this is essentially kind of your minimal definition of a person um and this is what people really want to express at their core about the object it has a first name and it has a last name but then if you kind of look at the typical use cases people want to be able to construct a person they want to say like hey i want to create a person jared parsons or i want to create a person rich lander they also want these types to work well in serialization i want to be able to pass my object through the serializer get the json out then i want to be able to pass that json back through the serializer and know that these two people these two person objects they're equal they represent the same set of data and this should remain true even through the act of serialization and deserialization and a lot of times when you start getting the kind of newer c sharp and you start looking at like c sharp seven where we added tuples or c sharp eight we had a pattern matching you want to start to be able to decompose these objects and deconstruct them and essentially pull this first name and last name out of the object and just treat them as individual fields you also want something we're seeing these squigglies by the way oh it's because we haven't enabled this behavior yet this is the work that we have to do in c sharp 8. we're starting here with here's the values that this is what i want to type this is the co this person object is the core of what i wanted to express i just have a first name and last name and here are all the things i want to do with that object but it all comes with a price and so like for instance the first squigglies is we have to get the constructor working and so in order to do that we're going to have to well i i see now we have to basically define a person object string first name string last name this is all we've all written this code i don't know how many times in our lives so now that takes care of kind of the first set of squiggles and then the second set of squiggles we have kind of we basically have to now tell our object okay we want to participate in deconstruction we want to work in all these pattern matchings and so we essentially have to define the opposite of a constructor a deconstructor and we ah we get to watch jared do a bunch of typos so now we see like with a little bit of work we've essentially got the program compiling now we have all the behaviors and if we f5 through the program what we're going to see um once my super fast laptop starts up is that it's printing out the json we are getting the deconstruction here we can see that it is pulling the names out and it is working in our pattern matching to see if rich is in the chat or not however you'll see up here that p1 and p2 equality has not is false it means we are not getting the equality we wanted out of this example and that's because we haven't even added equality to this system yet and to spare everyone the uh medium of watching me type equality we're just going to paste that in here and so that is adding the operator equals the various equal methods the hash codes and then going and adding the i equitable interface and as you can see like so now if we run the sample again what we're going to see is now equality is working we're getting deconstruction the pattern matching is working and we essentially have this functional type now but the cost of this type if you look it's about 35 lines of just basic boilerplate code that really only has one way to be written correctly and it's kind of tedious code and it's really kind of even error prone on a scale for instance if i come back later and add new fields to this type i have to go and update every single one of these methods in order to keep this to be a consistent correct definition and this is where records really come in and start shining they recognize that we define so many types like this in our program and if we don't the reason we often don't define these types is because we get lazy and we're like well i can skip a quality because i'm not really using it today um or maybe i'm gonna skip deconstruction because i just don't want to code it out but with records i can basically take this entire like 40 line definition and i can replace it with record person and now all the code i wrote before is still there it all compiles and if we execute this code we will see that i get the exact same behavior as before we still get the pretty json output our records are comparing equally all the deconstruction all the pattern matching is working and i've done it with just this tiny little definition this very concise thing and this is the core of what i originally wanted to say i just said i want a person and i want to have a first name and last name c sharp can you give me all the rest of this behavior uh so that makes sense um i played with records so uh you know i was able to see through to the to the end can you talk a little bit more about the equality nature because um you know most people in c sharp use uh classes and as you just demonstrated classes uh their quality uh semantic is based on object identity not based on content the content that they hold and um so can you give a sense of you know when people move to this new equality scheme like uh i guess their programs are gonna act differently um talk to how people should target this new way this new equality system so this equality system is really essentially embracing the idea that the types that we want to use as records really represent values they represent essentially something closer to structs than classes in a lot of ways because you're not saying that in into the the essentially the identity of an object is not the instance the identity of a record is really saying are all the values in my record equal and so that's very similar if you kind of want to take the mentality of structs where by default structs essentially do field by field comparisons and this is what you get with records as we're saying hey these are just a collection of values that we're attaching a very common set of behaviors too and one of those is equality right so this records very much kind of blur the lines uh between classes and structs like when people think about classes instructs today it's they either talk about passing by value as opposed to by reference or they talk about um stack allocation versus heap allocation um they actually mostly don't talk about this equality issue probably because it's just taken for granted um i guess like uh how do you how do you see people talking about records within that continuum i guess maybe just as you've just said yes it's just it's embrace it's just embracing that these when you you are right that they do sometimes blur the line between is this kind of more like a structure is this more like a class inequality is a place where it is much more like a struct the it's very much saying that the identity the actual identity the allocated object like doesn't really matter the identity what makes two op two records equal is basically are their constituent parts equal and that's why we prefer that's why they default to the struct base equality mechanisms okay so i don't know what you were wanting to talk about next but the thing that i was curious about was the immutability aspects of records yes so one of the beauty parts of this is um generally immutability in c sharp is something that you kind of have to pay for c-sharp is largely a mutable by default language where we have certain constructs where you can opt into immutability if you want for instance like read-only structs read only fields and what have you records is one place though where immutability is the default especially when you use positional style records as i have done here so you'll notice that if i come up here and i attempt to basically change the last name to another one you're going to see an error because this isn't this property does not have a uh an accessible setter and so i cannot set it um however records also provide like when you're dealing with immutable objects you do want to change fields you do want to change states but the way this is done with immutable objects is you essentially you create copies of objects and essentially change the state that matters to you in that new copy and in c sharp nine we allow you to do that with the thing records come with a thing called withers and so i could essentially change the value of last name by saying like i want to have p1 with the last name v oh that's my wife's last name um and so i want to basically and what this will do is it takes p1 it creates an entire copy of it changes the last name the bone and returns the new object and you'll see that this this um construct here looks a lot like object initializers which is very familiar c chart programmers and that's because it's it's the exact same construct like anything you can do the types of operations you can do in an object initializer you can do here you know if i misspelled my name as i want to do um but here's the thing like you're not and while immutability is the default in records um especially when you go with positional syntax it is by no means required if you were someone who was like you know i understand immutability has benefits i've read a lot about it but it's just not for me i'm really much more comfortable with having my record types be mutable that's completely fine you can add that in very easily by adjusting just to find the properties and have them be normal mutable properties as you can see up here nothing has changed i've gotten no new red squiggles you can see that this with expression where i create a copy of the object and change the field it's still working you're doing exactly what it did before but if i didn't like that if i said no i want in place i can now just say last name equals home and it works great so that all makes sense and it's it's great that people are going to have choice on mutability versus immutability um you know you've been able to do immutable style programming with c for some time it hasn't been as nice as this do you feel like um that people are going to finally adopt immutability as a kind of commonplace um pattern now that records are there and make it significantly more easy i think they so we're seeing like especially when we look at customer code i work on the c sharp compiler team we we interact with customers a lot you know when there are compiler bugs there are no compiler bugs but we interact with customers anyway um and uh so um and we can see a lot of the code and you can definitely see the transition that people are embracing immune billing more and more and i think records will help with that because they make it easy but actually that also kind of transitions in the next thing i want to talk about which is init only properties so just like if you look back in the history of c sharp when we do big features like records um it's usually composed of several other smaller features um like if you go back to link link was composed of anonymous types lambda expressions and extension methods one of the features that makes records work is what we call init properties yeah so init properties are this idea that up until now if you wanted immutability there was a price so if you wanted to for instance like let's go back to kind of the typical um like example so if you wanted to define an immutable type in c sharp a you would define a point type like this where you would say like hey i have a point it has an intense and a y and i have a constructor and the way i make it immutable is i basically have getters with no setters and this works fine this is a just a completely acceptable way to find immutable types in c sharp but it does have a limitation because it means now if i want to use this point like i'm actually now like limited in how i construct it i for instance can't say new point x equals 42 y equals 13. and this is something that i could have on all of my mutable objects but once i go to immutable code i can no longer do that and that means both that immutable code and c-sharp had less fluid construction and a higher cost to the type authors because it required them to write constructors even when they didn't need to but starting in c sharp nine we now have this thing called init properties and what these are is inits are a lot like centers except for one big difference they can only be used during the construction phase of the object and so what that means is i am now can define my point that is how they get internet i can remove the constructor and i can use object initializers just like i would be doing for a mutable object and you can see here that it's completely acceptable to set x while i'm building up the object but afterwards if i try to change that down here i'm going to get an error because the object's fully constructed at this point immutability has taken hold and i'm no longer allowed to change the value so have you found you know we've had several previews now of dyna five although i can't actually remember when some of these particular features came in but have you found some cases where people have started to transition more kind of large large style code bases over to these immutable features uh yes we have we've had um uh one nice thing is because of the way we preview c-sharp now where we actually check it into the main visual studio code base and allow customers to kind of flip a flag and start using these features before we're finished it makes adoption of these like much simpler um and so we have gotten a lot of feedback from customers on this init properties uh mostly massively positive feedback people are very excited about them and they have started transitioning to them as well as well as with records we have a number of customers who are starting to use them give us feedback and they really helped us kind of like finalize the design with that feedback nice okay so we should probably transition to um closing out this uh this video what would you like to leave people with so what i want to leave people with is basically that when they're looking at like they should when looking at their code and looking at all the times they've had these kind of like these small value based types like particularly if you look at your json serialization all these small little types you define just to pack a few values and kind of throw them around in your program you should really start to look at that and ask yourself like is this just a collection of values and if so should i start using records um to express them better when i adopt c-sharp nine and also looking particularly with init properties like can i make some of my objects some of the types i've made before where i had babies started using immutability can i make it a lot simpler and a lot more fluid for my customers to use by embracing the net properties makes sense uh so age-old question are we to start seeing people defining multiple types in a single file because of records uh i really hope so i mean if people if people really want to have like 21 line files in their you know project i mean more power to you uh i would highly encourage you though to consider having records as a way to change your mentality and maybe let yourself define a few types in the same file yeah awesome okay jared thanks for being on the show uh you know i think people people love c sharp and um i think they're gonna love c sharp nine awesome thanks so much for having me awesome [Music]

Channel: dotNET

Views: 57,532

Rating: 4.883297 out of 5

Keywords: .NET, dotnet, .NET Core, .net 5, dotnet 5, C#, Csharp, C# 9, Visual Studio, Records, Immutability, Language, programming, programming languages, Software, Microsoft

Id: qiuzCWwYe0Y

Length: 22min 38sec (1358 seconds)

Published: Tue Oct 06 2020