0:00 - Intro 0:57 - Getting started: demo console app 2:16 - How to use Records 3:45 - Records: declared and explained 6:55 - Record features 13:00 - Records vs. Class: ToString() override 17:04 - Records vs. Class: compare objects 20:49 - Records vs. Class: compare object reference 22:10 - Records vs. Class: compare object == 24:31 - Records vs. Class: object Hash Code 27:10 - Records vs. Class: Recap 28:13 - Records vs. Class: Deconstructor 31:32 - Records vs. Class: Record Object copy 34:30 - About Records 36:19 - Record property access modifier 40:12 - Other Properties in Records 42:53 - Methods in Records 43:56 - Full Properties in Records 47:33 - Recap 49:49 - Record inheritance 52:57 - *Why Records?* 53:53 - /*Benefits*/ 57:45 - /*When to use Records*/ 1:05:10 - /*When not to use Records*/ 1:14:31 - Summary and concluding remarks (+ bonus: top level call args in C# 9) You forgot the time codes ;)

Thanks for such a detailed explanation, Tim. You are the best at explaining complex concepts and having the perfect analogies to better understand them. The house and address analogy for class addresses was brilliant.

Great educational presentation with high quality! And the chapter breakdown makes it easy to jump between the parts you find most useful.

Thank you Tim, seriously this is the first time I know about Records in .Net core. Please give us all updates in C# as much as you can.

Superman Tim Corey, could not resist getting into yer slipstream. Really great to have you on board. Thanks for yer forte which appears to be a mind boggling easy way to get into web development.

Thanks Tim, I knew I could only get vivid description of the updates from you. Looking forward to the Blazor updates.

This is amazing; I was recalling concepts from Java Script and Java. It sounds like the smart people at Microsoft worked so hard to make available capabilities that make coding a lot easier. Things that in other languages you just have to remember how to do. But now in C# you have specific methods with specific results. I love it. And you explained it so well as always. Nothing against other languages I love them all, and wish I had time to learn more about them. But I am so glad I decided to learn C# and other Microsoft technologies.

Great video, many thanks Tim! I'm definitely going to recommend your videos to my co-workers.

Huge addition to C#, introduced with a great video! Thank you!

Thanks Tim, I wish you work for MS because your explanations are always crystal clear, unlike MSDN articles which sometime looks like "how to draw Owl" meme.

Thank you so much Tim, records definitely needed their own video.

Great, in my humble opinion, i think you deserve the c# crown

Awesome material, and a great explanation! For those trying it at home, there are a couple of syntax simplifications you can use: public record Record2(string FirstName, string LastName) { internal string _firstName = FirstName; internal string FirstName => _firstName.Substring(0, 1); public string FullName => $"{ FirstName } { LastName }"; }

Thank you very much for this valuable knowledge. Records - A value-added to C#

Thank you so much for the awesome video! Everything was very well explained! Only thing I was still wondering was if Records can inherit Interfaces or not. I searched the web and I see that they can! :)

Absolutely top content Tim!! More power to you

Great video and Thanks for the detailed explanation Tim....

Thank you Tim! This is a high quality Knowledge.!

Thanks a lot for this amazing video! You should definitely get used to the "Ctrl+D" shortcut tho :D

Thanks for all the content you always deliver. I made huge progress in C# over the last year and your videos played a big part on that :) I have two examples where I'm still not sure what I would use: 1. A Coordinate. Usually it was a prime example for a struct. But with all the features of a record, i would tend to create it as a record now. The easy comparison, an easy destructor, immutability and also the ability to have for example a 3DCoordinate inherit from Coordinate. But this makes me wonder, what are cases to use a struct then? (I almost never used structs in the past, do i don't know that much about those) 2. Let's say we have a simple n:1 relationship between city and person (inhabitants) and none of the cities properties will ever change. Just the objects in the Collection for inhabitants. Would it make sense to use a record here, if i want to guarantee immutability?

Hi Tim, I'm going to Copenhagen academy in IT learning and I'm doing web programming in server, all my fellow students are more interested in your videos than in our teacher, I post all your free videos on our forum, well done Tim, I also buy your courses and learn a hell of a lot from them many greetings Knud Nielsen Denmark

Thank you so much Tim, no matter what level a developer is, ur uploads are great !

Great video! Thoroughly enjoyable. I would just like to mention a couple of more use cases that records may be useful for. One thing I especially like about them, is how they can be declared with very little additional boiler plate code. They can be declared almost completely in domain language and they are compact, making them easy to read for non-tech oriented domain experts. They can be used as a tool for defining the domain knowledge in code, and being understandable between domain experts and developers! Another thing they can be really useful for is when combined with the new pattern matching features (Especially switch expressions) - They can be used as a reasonable substitute for discriminated unions, as they are able to be derived from - This, combined with pattern matching is a very powerful combination, and I think would probably warrant its own video. I loved the explanations, and I dont know why MS made the choice to allow mutability.

Great explanation of records in C# 9! Thanks Tim

Thanks Tim, this is a great video!

☝🏾🔥👍🏽 That is a very good deep dive into records.

Excellente video indeed. Everything was thoroughly explained. Thank you!

You forgot your fav. Putting records in lists. It works. Thanks for the video :) Also 11:57 ctrl+d.

Thank you very much TimCorey you explain very well. I guess we also can use records for const variables

Oh my god, this video contains huge amount of infomation. Thanks a million!

Sir, I love the way you teach.

Very informative video. Other resources and even books don't cover that much about records!

बहुत ही अच्छा वीडियो टीम जी आप ऐसा ही ज्ञानपुर्वक वीडियो हमारे लिए लाते रहिए । हमारी दुआ आपके साथ है । धन्यवाद 🙏

Thank you Tim for this awesome content. The comment section is educational as well.

Thank you very much for this valuable knowledge.

Wonderful explanation, very useful, thank you so much!

Very informative. I did a couple of projects using Akka.Net. Since the objects passed around by Akka must be immutable, records are an excellent way to encapsulate the Akka message data and you don't have to worry about accidentally changing your object.

Woah as you said new shiny stuff, but "why"... I liked that you answered that question. Great Video

Great Tutorial. I enjoyed it and got a lot out of it.

Thank you so much for sharing your vast knowledge with us, Mr. Corey! I think I am going to use this records for my DTO objects. This should work fine I guess because I don’t think they (DTOs) should be mutable.

Perfect timing, as I head for my lunchtime coffee !

Thank you for this awesome C# Record.

At 10:38 of the video when you use the trick to initialize the field value from the constructor, it's even faster if you do Control + Dot on the private field instead of on the parameters of the constructor. In other words have an emty constructor then do Control+Dot on the field and select the option to "Initialize from Constructor". Long video but great thanks Tim

Hey Tim, Good stuff, thankyou. Call me crazy but I could swear you said multiple times "location on disk" when differentiating between a record and class You said it so many with confidence it makes me think i'm missing something. (one of us is going crazy :))

Nicely done. Thank You!

excellent work in this video, thanks

Really great explanation!

Hey Tim, love this video. Totally unrelated but I wanted to let you know that if you do ctrl + enter at the end of a line, it will copy it and put in the next line. I saw you doing a manual copy paste :) Nice shortcut when you want to copy and paste a line. Thanks again for the vid.

Thanks for another great video Tim! At 10:58, what I have also learned from the 'Ctrl + .' boiler plate reduction is you can type your 'firstName' and 'lastName' parameters before typing them as properties. When you 'Ctrl + .' it will give you the option to create the parameters as properties or fields. I have found this helpful in creating DTOs and dependency injection.

Hi Tim great video as always. I'm watching all yours video and very often you are copying line of the code using copy and paste. I have found very useful to put the cursor on the line that I want to copy and press CTRL+D to copy whole line and paste below. Thank you for sharing your knowledge.

Great video. Thanks a lot!

Great video!!

Great video Tim! Very clear like all your others one. Just one small observation! public record User1(int Id, string FirstName, string LastName) : Record1(FirstName, LastName); I think that this line is a bit of confusing because it's the same thing of write: public record User1(int Id, string FirstName, string LastName); The example that would have made the most sense would have been to inherit from Record2 in order to show more clearly that the methods/properties/etc will be inherited too

Great as always, thank you Mr. Corey! So records are immutable unless you add setters and make them mutable, got it :-).

Once I saw a Python talk (I also code in python) and in that talk one thing stuck with me: "Every feature [...] has at least one or two very clear and unambiguous mental models [...] for where is actually useful." The talk was about some python features, like metaclasses, but I found that this thought process can be applied for most of programming in general. I believe is more importante to understand a feature in a abstract level (its mental model/purpose) rather then all the technicalities that you can look up in the documentation. Same goes for records. What is a record, in real life? According to a dictionary: "1. a thing constituting a piece of evidence about the past, especially an account kept in writing or some other permanent form." It stores information about the past. We can't change the past, so we shouldn't change records. So there you go, records are for things that we cannot, or should not, change over time. Those mental models really help me get a hold of when to use certain features.

Very nice explanation, thanks

Thanks you for that tutorial. Is it amazing !! :)

10:30 There's actually an even faster way to do it, you select all the properties that you want in your constructor, then hit alt + enter, there's an option that says generate constructor, it will generate all the constructor for you. You don't have to write anything. I use visual studio 2022 but idk if you can use it in 2019 and below.

Hi, I was looking for a spread operator in C#, I think record just fit with the Blazor-state. Great tutorials, thanks.

More people need to watch this video!! I was having a hard time understanding records and this cleared everything up!

I'm using records with Dapper now, and it's working out just fine. Then, I have a different approach to data that needs to be changed/updated: I use the copy feature of records. That makes it distinctly clear exactly which fields will be changed. That's a lot more readable than using classes and having to copy every property. Using a record copy exposes clearly what my intentions are, and leaves much less space for bugs to hide in. All my records are still immutable, my code is brief and focused on what I do. it's good :)

Great stuff!

Wow, I missed the ability to omit a type during instantiation in c# 9. That's nice, my eyes crossed when you first used it.

Thanks Tim, that’s a good video. I have a couple of questions: records support generic, and the other one is if do you think that is a good idea that a record has a class as property. I’m designing a generic results from transactions that returns if the transaction was succeeded, has errors and if it is success, return the object persisted in the db

I really thank you for this video tutorial

awesome, thanks again

Thanks coach!

After watching I was dying to check this out: static void Main() { var r1 = new Record1(); var r2 = new Record1(); Debug.Print($"r1: {r1}"); Debug.Print($"r2: {r2}"); Debug.Print($"r1 == r2: {r1 == r2}"); } public record Record1() { public int RandomNumber => new Random().Next(0, 100); } What do you think the last Debug.Print will produce? Take your guess! :D P.S. Thank you Tim for another great video!

thanks Tim for the time and effort , try using CTR+D to duplicate lines in vs

I certainly found the use case for records in our project. For serverside caching, we calculate the SHA256 hashcode of the requests to identify if the request getting repeated, I see records as a potential replacement for classes there as we don't need to change the incoming requests and want the same hashcode every time the same request comes. Scope to get rid of SHA256.

@ IAmTimCorey I like using record's when working with Json (System.Text.Json). I write a record that describe my format, then I serialize and desterilize it when needed. Also, I like using the custom Deconstruct void in my record to do Pattern Matching.(Fun Stuff)

34:43 Difference between struct and record 36:02 Records can have methods and can inherit from other records 52:59 Why we need records

"Personality, I wish that classes would do this". Same. For a lot of my classes I simply override ToString() to output a json representation of the class. For the className I simply declare it as a string.

Thank you for the big fonts.

Great video as always! just got around to learning this. 1 quick question - where would you define those records? in classes, we usually define each class in its own file is this the same for records?

Hey @Tim about inheritance can class inherit from record to save writing code ? ty

I would add that records are useful when writing more functional code (c# seems to be migrating to be a hybrid language) and if you are using records it should be records and immutability all the way down. A developer can run into issues if a record has a class that is mutable making the record shallow immutable. They do a solid 85% of the work for us but you can still shot yourself in the foot.

Thanks!

Many thanks for this video. I have a couple of queries: 1. Can we place records in a list? 2. Can we use them in as Models in MVVM (E.G. PersonModel)?

Tim, thanks for this in-depth video. I have one question, can we override Equals like we can in classes? Use case for this can be when I want to compare only selective fields for equality.

Excelente video, the only observation I see is that if records are basically classes with add in functionality, how they interact with interfaces?

Thank you, suggest to add how to apply attributes to properties : public record Record1( [property: JsonPropertyName("id")] string Id)

thank you 👍👌🏻

Wow, its a real deep dive in to record.. I wondering what is a way to use a record in foreach or for loop?

I know this is old but once you override the properties you have to make a constructor and deconstructor for the overridden value for it to retain its original functionality, the reason is you changed it to a non-positional record, similar to how a list works. You told the record I need this to behave differently so it pulled the value from its position does the changes you declare then pops it back at the end as it moves in order. So in your example Last name moves to the front of the order and the changed Firstname moves to a new position behind it. The reason you can use { Get; Set; } is because you need to be able to use them for a public record struct as a struct cant be {get; init; } your case in Do not do is an exploitation of this behavior by hybridizing a loophole. When making the record a struct it takes on the behavior of a value type not a reference type removing the need of immutable. In fact as an example: public record struct Point(float x, float y) //initializes as public struct Point { public float X { get; set; } public float Y { get; set; } public Point(float x, float y) { X = x; Y = y; } } unlike public record Point(float x, float y) //initializes as public class Point { public float X { get; init; } public float Y { get; init; } public Point(float x, float y) { X = x; Y = y; } }

Tim Sharp Corey 👍👌

I'm not sure about 1 part regarding inheritance: For example there is base Employee record and its derived record Manager. If I write Person p = new Manager(...); As expected I dont have access to Manager members untill I do explicit cast, but. Why p.ToString() prints Manager and even its members in {}, instead of Person? I have only guesses. Is it overrides ToString at runtime or even implicitly converts whole p instance ?

Thanks Tim! Would be great if you could condense these to 20 min max. Trying to watch this using 2x but it still feels slow.

@8:00 you are comparing init properties to the record and that your previous video etc. and that you can set those values via curly braces during construction. Is there a way to do that with Records? When I am trying it, I am required to use the constructor. Is there some option I missed in your video to allow me to use curly braces construction?

Great! 😊

the equality checks make records compelling for me. I worked on a project where we kept multiple versions of documents in mongo, so on ingress (creation) we would find an existing, and compare so as to create a new version. Needless to say, we had to override gethashcode based on each of the properties, and then write/maintain equality tests for each such class.

Hello Tim, I listened to the whole thing. Very informative, but one last bit you said around 1:13:15 tripped me. You said the record clone is making a shallow copy. But how so? We didn't have any reference types as any properties in the record to begin with. What exactly is shallow copied when you clone a record? Did you mean the reference to the record itself is reused on a clone?

Great info Tim! Much appreciated. I crack up every in you mention 'is/is not' since those have been in VB4 (pre-DotNet) as well as var (aka..Dim) In a class I usually override ToString(), add properties to a StringBuilder to return property names and contents. Records eleminate that extra code. Cool!

5:58 - Records act like value types, but they are not 7:44 - Meaning of "init" keyword 8:03 - Records are immutable 17:22 - Records equality 21:04 - Reference equality 23:27 - Equals() and == are not the same 28:19 - Record deconstructor 32:00 - Copying and modifying records

Is it possible to cast record to class? Let's say they have the same properties. First what comes to my mind is using reflection to map the properties. What if i wanted to use json.net to map a json to a record? Does the reflection with classes and records work the same way? (I assume it does since you said record is just a fancy class)

How do records differ from readonly struct? And how does changing the properties of a record like first letter for firstname the equality between records? Is Tim Corey the same as Timothey Corey? Can you also make them case insensitive? Or if one of your properties is a List does,t that break the immutability and the equality? When you do inheritance and you cast user1 to record1 and compare two different Id users with the same first and last name will they equal true?

I found a case where something should be a record even if there is one property you can write to. Here is a sample case. public record ConnectionInfo(string ConnectionID, string UserID, bool IsConnected) { public bool IsConnected { get; set; } } By still using records, I get the benefits of equality. Plus I get the benefit of having everything in the constructor and if i need to read the values, then i get that benefit as well. There can be many cases where most of the properties are immutable but there is one exception. In that case, I like a person can still use records to still have less boilerplate code.

45:26 Actually, C# will handle way better that we will, TBH. I like the idea of having immutable data philosophy and being closer and closer to functional paradigms in this C# new era. In my opinion, record types comes with lots of extra stuff which is only shadowing what they should be, which is *immutable data structures* . The idea of redeclaring properties and the ability to declare methods makes records less responsable. *Data structures must store data* , nothing more, nothing else. If any system needs to hide some properties from a certain data structure or maybe remapping some of their properties, then the system must do it by itself (by implementing filters, mappers, handlers, etc), not the actual data structure.

Interesting catch on the use of the internal keyword. Though it should be seen by the declaring class, it's not. Unless M$ considers the declaring class to be the record itself, as it is declared there. But you can sell see it externally, Hmmmmmm. Weird.

Hello, Tim. Thank you for this lesson. It was very interesting and useful. But I have a question. As I know all types for collections are reference types. And I can't use List or Array type for property in record because their hash codes will be different for different objects. So how can I work with record type that has to contain collection?