Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

Connect_Whats_New_in_C_Sharp_6_0_ENU

0 (0 Likes / 0 Dislikes)
  • Embed Video

  • Embed normal player Copy to Clipboard
  • Embed a smaller player Copy to Clipboard
  • Advanced Embedding Options
  • Embed Video With Transcription

  • Embed with transcription beside video Copy to Clipboard
  • Embed with transcription below video Copy to Clipboard
  • Embed transcript

  • Embed transcript in:
    Copy to Clipboard
  • Invite a user to Dotsub
[What's new in C# 6] [Mads Torgerson] [male speaker] Hi, I'm Mads Torgerson, and I'm a program manager on the C# language design team. I'll give you a quick tour through the features we are adding to the next version of C#. [Design Philosophy] In C#6, we decided not to add big new concepts that you have to wrap your head around. Instead, we wanted to give you a lot of small, but useful, features that help clean up your code, give it a boilerplate, and let your intent stand out more clearly. Let's go through these features and have a look. [Getter-only auto-properties] We'll start with auto-properties— in current C#, auto-properties must have setters. This puts immutable data types at a disadvantage, and that's a shame. So we now allow getter-only auto-properties. The way the compiler implements them, their backing field is read-only, just like you would have written it, and just like read-only fields, they can be assigned from the constructor. That doesn't call a setter. There is no setter. It just assigns directly to the backing field to initialize it. [Initializers for auto-properties] You can also now initialize auto-properties directly in the same way as with fields. The initializer, again, just assigns into the underlying field. Initializers work on the new getter-only auto properties as well as the good, old-fashioned ones with setters. But in this example, let's stick with getter-only auto-properties initialized by the constructor. [Using Static Members] We're introducing a new kind of using clauses that refer to types instead of name spaces. What this does is to put the static members of that type directly into scope, hence the name. If you look at this static method call, for instance, you don't need to prefix it with a class name, math, anymore— you can just call the square root method directly. So that's great for when a static class, like math, is really just a collection of functions you want to call liberally throughout your code. It's also convenient for using enum members directly without having to prefix them with a type name every time. Now, this can be overdone. But I've always felt that Monday's pretty clearly a day of the week and yellow is quite obviously a color. I don't gain much from having to state that every time in my code. [String interpolation] String.Format is a very useful and versatile API, but it's bulky, and the business with the placeholder numbers gets confusing. It's error prone, and it tends to muddle your intent. It would be better if the values to format in occurred in their place, and that is what this string interpolation syntax here is for. Let's do that in slow motion. This call to String.Format goes away and we add a dollar sign to signal that this is an interpolated string. Then we remove the placeholder numbers, leaving holes into which we put the expressions to be formatted in right there where they belong. Now push it all together, and it's really clear and terse. [Expression-bodied methods] There are many methods like this, where the body is just a single return statement with the result. For lambda expressions, we already give you a way of getting rid of this boilerplate with a single expression rather than a statement body. So why not do the same for methods? Inspired by lambda syntax, we used the lambda arrow to let you implement a method with just a single expression. This goes for other kinds of function members, too. For computer properties, it's often like this— a getter with a single return statement. That's even more boilerplate than the method with two levels of curly braces required. Now you can just write the whole thing like this— a lambda arrow and an expression. There's not even a get keyword. That's implied with the syntax. Let's pause to appreciate how much simpler and clearer this whole class declaration has gotten. All this nipping and tucking has really tightened it up from what you have to write today. This is the kind of effect we hope to have on your everyday code with C# 6. But there are still a few more features to go. [Index Initializers] Here's a method to turn points into JSON objects. Today, you can initialize properties in an object initializer, but index setters like these still have to be assigned in separate statements. Now we're extending object initializers to let you assign to indices inside them with the obvious square bracket syntax here. So the J object can be initialized declaratively in one expression. That, by the way, leads to a cascading effect of simplification. We don't need the temporary variable anymore, and now we have this pattern with just a single return statement, so in fact, we can turn the whole body into an expression, just like you saw a little bit earlier. [Null-conditional operators] Let's also look at a method to turn JSON back into point objects. The logic to actually do that is just one line of code. The bulk of the method, though, is taking out by checking before you do that, that you actually can do it, and most of that checking is about checking for null. First, we check that JSON itself is not null before we index into it. Then we check twice here that the result of indexing isn't null before we access its type property. Null conditional operators are about making all this null checking here fade into the background. Let's first look at those innermost null checks to get to the type property. We've now removed the explicit null checks and instead made use of this new question dot operator. It works like this—if the left-hand side is null, the whole thing is just null. If the left-hand side is not null, then we can do the dot, and that becomes the result. If null, then null. If not, then dot. You'll sometimes hear people refer to the question dot as the Elvis operator. If you look at it and you can see why, it's like two eyes with a swoop of hair on top, like Elvis. Meanwhile, we still have that initial null check to see if we can index, but indexing can be done in a null-conditional way, too. You just insert a question mark In front of the square brackets, and now they only happen if the receiver is not null. Now the whole if condition just expresses your core intent, which is, if JSON has x's and y's with integer types, then do the following. The essence stands out. The rest fades into the background. A great use of the null-conditional dot operator is for triggering events. Today, you trigger an event like this, except the delegate could be null, of course. So you first have to check for that, but this way of checking isn't threat-safe— someone might unsubscribe the last event handler just after you checked. So now it's still null when you get to the dot. Instead, you need to first copy the delegate reference to local before you check and trigger, and now it's gotten really unwieldy. All you wanted to do was trigger an event. With a null-propagating operator, this is simply not a problem anymore. You can just conditionally call the invoke method on the delegate. The effect is that the delegate will be called only if it's not null. So I expect this to become a common pattern in C# code. [The nameof operator] Quite often, you need to get the name of a program element as a string, like with point here. The problem with that is, if you rename point with a refactoring, for instance, you're likely to forget changing the string, which is now out of sync. The nameof operator gets you that string, but it knows what program element you're talking about and ensures that it actually exists. So if you do rename it, the string changes, too. [Exception filters] We have made a few improvements around catch and finally clauses. Our sister languages—Visual Basic, F#— they both allow a catch block to filter its exceptions before catching them. Now C# allows it, too. This is better than catching and rethrowing, because when you rethrow an exception, you lose the information about where it originally occurred. It also just looks better, right? [Await in catch and finally] You can now have await expressions in catch and finally blocks. This was really just an implementation challenge, shall we say? And we've now figured out an efficient solution to it. So lifting this restriction should be welcome news, . It's a common enough scenario with more and more APIs being Async, so why wouldn't you want to call them in catch and finally blocks? And the workarounds that you have to use today, they're pretty nasty. [Learn more at github.com/dotnet/roslyn] I hope you're as excited as I am to get to clean up your code with C# 6. If you want to learn more, head on over to dotnet/roslyn on github, which is where we hang out these days. I publish the language design notes there on a running basis, and there's lots of community discussion. Also, you can find links to more resources there. So have fun with C# 6 and thanks for watching.

Video Details

Duration: 7 minutes and 49 seconds
Country: United States
Language: English
License: All rights reserved
Genre: None
Views: 48
Posted by: duncanma on May 14, 2015

----- (Please provide translations for these languages: Chinese (Simplified) (chi_hans), Chinese (Traditional) (chi_hant), Czech (cze), English (eng), French (France) (fre_fr), German (ger), Italian (ita), Japanese (jpn), Korean (kor), Polish (pol), Portuguese (Brazil) (por_br), Russian (rus), Spanish (spa), Turkish (tur).)

Caption and Translate

    Sign In/Register for Dotsub to translate this video.