Yesterday we announced the first preview of both Visual Studio 2019 (Making every developer more productive with Visual Studio 2019<\/a>) and .NET Core 3.0 (Announcing .NET Core 3 Preview 1 and Open Sourcing Windows Desktop Frameworks<\/a>). One of the exciting aspects of that is that you get to play with some of the features coming in C# 8.0! Here I am going to take you on a little guided tour through three new C# features you can try out in the preview. Not all C# 8.0 features are available yet. If you want an overview of all the major features, go read the recent post Building C# 8.0<\/a>, or check the short (13 mins) video “What’s new in C# 8.0” on Channel 9<\/a> or YouTube<\/a>.<\/p>\n First of all, download and install Preview 1 of .NET Core 3.0<\/a> and Preview 1 of Visual Studio 2019<\/a>. In Visual Studio, make sure you select the workload “.NET Core cross-platform development” (if you forgot, you can just add it later by opening the Visual Studio Installer and clicking “Modify” on the Visual Studio 2019 Preview channel). Launch Visual Studio 2019 Preview, Create a new project, and select “Console App (.NET Core)” as the project type. Once the project is up and running, change its target framework to .NET Core 3.0 (right click the project in Solution Explorer, select Properties and use the drop down menu on the Application tab). Then select C# 8.0 as the language version (on the Build tab of the project page click “Advanced…” and select “C# 8.0 (beta)”). Now you have all the language features and the supporting framework types ready at your fingertips!<\/p>\n The nullable reference types feature intends to warn you about null-unsafe behavior in the code. Since we didn’t do that before, it would be a breaking change to just start now! To avoid that, you need to opt in to the feature. Before we do turn it on, though, let’s write some really bad code:<\/p>\n If you run it you get, of course, a null reference exception. You’ve fallen into the black hole! How were you supposed to know not to dereference That’s the question that nullable reference types set out to answer! So let’s turn them on! For a new project you should just turn them on right away. In fact I think they should probably be on by default in new projects, but we didn’t do that in the preview. The way to turn them on is to add the following line to your .csproj file, e.g. right after the LanguageVersion that was just inserted when you switched to C# 8.0 above:<\/p>\n Save the .csproj file and return to your program: What happened? You got two warnings! Each represents one “half” of the feature. Let’s look at them in turn. The first one is on the It complains that you are assigning null to a “non-nullable type”: Whaaat?!? When the feature is turned on nulls are no longer welcome in ordinary reference types<\/em> such as How do<\/em> you ask for it? By using a nullable reference type, such as The warning goes away: we have explicitly expressed the intent for this variable to hold null, so now it’s fine.<\/p>\n Until the next line of code! On the line<\/p>\n It complains about the The warning goes away! Why? Because the compiler can see that you only go to the offending code when This uses the null conditional indexing operator As you can see, the feature keeps you honest while you code: it forces you to express your intent whenever you want null in the system, by using a nullable reference type. And once null is there, it forces you to deal with it responsibly, making you check whenever there’s a risk that a null value may be dereferenced to trigger a null reference exception.<\/p>\n Are you completely null-safe now? No. There are a couple of ways in which a null may slip through and cause a null reference exception:<\/p>\n But on the whole, if you use the feature extensively (i.e. turn it on everywhere) it should take care of the vast majority of null dereferences.<\/p>\n It is definitely our intention that you should start using the feature on existing code! Once you turn it on, you may get a lot of warnings. Some of these actually represent a problem: Yay, you found a bug! Some of them are maybe a bit annoying; your code is clearly null safe, you just didn’t have the tools to express your intent when you wrote it: you didn’t have nullable reference types! For instance, the line we started out with:<\/p>\n That’s going to be super common in existing code! And as you saw, we did get a warning on the next line, too, where we tried to dereference it. So the assignment warning here is strictly speaking superfluous from a safety standpoint: It keeps you honest in new<\/em> code, but fixing all occurences in existing<\/em> code would not make it any safer. For that kind of situation we are working on a mode where certain warnings are turned off, when it doesn’t impact the null safety, so that it is less daunting to upgrade existing code.<\/p>\n Another feature to help upgrade is that you can turn the feature on or off “locally” in your code, using compiler directives To learn more about nullable reference types check out the Overview of Nullable types<\/a> and the Introduction to nullable tutorial<\/a> on docs.microsoft.com<\/a>. For a deeper design rationale, last year I wrote a post Introducing Nullable Reference Types in C#<\/a>. If you want to immerse yourself in the day-to-day of the design work, look at the Language Design Notes<\/a> on GitHub, or follow along as I try to put together a Nullable Reference Types Specification<\/a>.<\/p>\n C# is getting more expressiveness around working with indexed data structures. Ever wanted simple syntax for slicing out a part of an array, string or span? Now you can! Go ahead and change your program to the following:<\/p>\n Let’s go to that bit of code that iterates over the array of names. Modify the It looks like we’re iterating over names 1 to 4. And indeed when you run it that’s what happens! The endpoint is exclusive<\/em>, i.e. element 4 is not included. The endpoints of a range expression don’t have to be ints. In fact they’re of a type, This lobs off an element at each end of the array, producing an array with the middle three elements. Range expressions can be open at either or both ends. Ranges aren’t just meant for use in indexers. For instance, we plan to have overloads of Both are synchronous, though: the results better be ready when they are asked for, or the thread blocks! First, let’s add another Now let’s simulate that Of course we get an error that you can only Now we’re told that we’re not returning the right type for an async method, which is fair. But there’s a new candidate on the list of types it can<\/em> return besides the usual Just like that we’ve produced an asynchronous stream of strings! In accordance with naming guidelines, let’s rename Now we get an error on this line in the Which doesn’t know how to foreach over an It’s the version of foreach that takes an async stream and awaits every element! Of course it can only do that in an async method, so we have to make our Now all the squiggles are gone, and the program is correct. But if you try compiling and running it, you get an embarassing number of errors. That’s because we messed up a bit, and didn’t get the previews of .NET Core 3.0 and Visual Studio 2019 perfectly aligned. Specifically, there’s an implementation type that async iterators leverage that’s different from what the compiler expects. You can fix this by adding a separate source file to your project, containing this bridging code<\/a>. Compile again, and everything should work just fine.<\/p>\n Please let us know what you think! If you try these features and have ideas for how to improve them, please use the feedback button in the Visual Studio 2019 Preview. The whole purpose of a preview is to have a last chance to course correct, based on how the features play out in the hands of real life users, so please let us know!<\/em><\/p>\n Happy hacking,<\/p>\n Mads Torgersen, Design Lead for C#<\/p>\n","protected":false},"excerpt":{"rendered":" Take C# 8.0 for a spin Yesterday we announced the first preview of both Visual Studio 2019 (Making every developer more productive with Visual Studio 2019) and .NET Core 3.0 (Announcing .NET Core 3 Preview 1 and Open Sourcing Windows Desktop Frameworks). One of the exciting aspects of that is that you get to play […]<\/p>\n","protected":false},"author":1379,"featured_media":21739,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[756],"tags":[4,9,46,147],"class_list":["post-20485","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-csharp","tag-net","tag-net-core","tag-c","tag-visual-studio"],"acf":[],"blog_post_summary":" Take C# 8.0 for a spin Yesterday we announced the first preview of both Visual Studio 2019 (Making every developer more productive with Visual Studio 2019) and .NET Core 3.0 (Announcing .NET Core 3 Preview 1 and Open Sourcing Windows Desktop Frameworks). One of the exciting aspects of that is that you get to play […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/20485","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/1379"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=20485"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/20485\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/21739"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=20485"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=20485"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=20485"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Getting ready<\/h2>\n
Nullable reference types<\/h2>\n
using static System.Console;\n\nclass Program\n{\n static void Main(string[] args)\n {\n string s = null;\n WriteLine($\"The first letter of {s} is {s[0]}\");\n }\n}\n<\/pre>\ns<\/code> in that particular place? Well duh, because null was assigned to it on the previous line. But in real life, it’s not on the previous line, but in somebody else’s assembly running on the other side of the planet three years after you wrote your line of code. How could you have known not to write that?<\/em><\/p>\n<Nullable>enable<\/Nullable>\n<\/pre>\n
null<\/code> in this line:<\/p>\nstring s = null;\n<\/pre>\n
string<\/code>! Because, you know what, null is not a string<\/em>! We’ve been pretending for the last fifty years of object-oriented programming, but actually null is in fact not an object: That’s why everything explodes whenever you try to treat it like one! So no more of that: null is verboten, unless you ask for it.<\/p>\nstring?<\/code>. The trailing question mark signals that null is allowed:<\/p>\nstring? s = null;\n<\/pre>\n
WriteLine($\"The first letter of {s} is {s[0]}\");\n<\/pre>\ns<\/code> in s[0]<\/code> that you may be dereferencing a null reference. And sure enough: you are! Well done, compiler! How do you fix it, though? Well that’s pretty much up to you – whichever way you would always have fixed it! Let’s try for starters to only execute the line when s<\/code> is not null:<\/p>\nif (s != null) WriteLine($\"The first letter of {s} is {s[0]}\");\n<\/pre>\ns<\/code> is not<\/em> null. It actually does a full flow analysis, tracking every variable across every line of code to keep tabs on where it might be null and where it probably won’t be. It watches your tests and assignments, and does the bookkeeping. Let’s try another version:<\/p>\nWriteLine($\"The first letter of {s} is {s?[0] ?? '?'}\");\n<\/pre>\ns?[0]<\/code> which avoids the dereference and produces a null if s<\/code> is null. Now we have a nullable char?<\/code>, but the null-coalescing operator ?? '?'<\/code> replaces a null value with the char<\/code> '?'<\/code>. So all null dereferences are avoided. The compiler is happy, and no warnings are given.<\/p>\n\n
new string[10]<\/code>, we create an array full of nulls, typed as non-null string<\/code>s. We don’t warn on that, because how would the compiler keep track of you initializing all the array elements? <\/li>\n<\/ul>\nstring s = null;\n<\/pre>\n
#nullable enable<\/code> and #nullable disable<\/code>. That way you can go through your project and deal with annotations and warnings gradually, piece by piece.<\/p>\nRanges and indices<\/h2>\n
using System.Collections.Generic;\nusing static System.Console;\n\nclass Program\n{\n static void Main(string[] args)\n {\n foreach (var name in GetNames())\n {\n WriteLine(name);\n }\n }\n\n static IEnumerable<string> GetNames()\n {\n string[] names =\n {\n \"Archimedes\", \"Pythagoras\", \"Euclid\", \"Socrates\", \"Plato\"\n };\n foreach (var name in names)\n {\n yield return name;\n }\n }\n}\n<\/pre>\nforeach<\/code> as follows:<\/p>\nforeach (var name in names[1..4])\n<\/pre>\n
1..4<\/code> is actually a range expression, and it doesn’t have to occur like here, as part of an indexing operation. It has a type of its own, called Range<\/code>. If we wanted, we could pull it out into its own variable, and it would work the same:<\/p>\nRange range = 1..4; \n foreach (var name in names[range])\n<\/pre>\n
Index<\/code>, that non-negative ints convert to. But you can also create an Index<\/code> with a new ^<\/code> operator, meaning “from end”. So ^1<\/code> is one from the end:<\/p>\nforeach (var name in names[1..^1])\n<\/pre>\n
..^1<\/code> means the same as 0..^1<\/code>. 1..<\/code> means the same as 1..^0<\/code>. And ..<\/code> means the same as 0..^0<\/code>: beginning to end. Try them all out and see! Try mixing and matching “from beginning” and “from end” Index<\/code>es at either end of a Range<\/code> and see what happens.<\/p>\nstring.SubString<\/code>, Span<T>.Slice<\/code> and the AsSpan<\/code> extension methods that take a Range<\/code>. Those aren’t in this Preview of .NET Core 3.0 though.<\/p>\nAsynchronous streams<\/h2>\n
IEnumerable<T><\/code> plays a special role in C#. “IEnumerables” represent all kinds of different sequences of data, and the language has special constructs for consuming and producing them. As we see in our current program, they are consumed through the foreach<\/code> statement, which deals with the drudgery of obtaining an enumerator, advancing it repeatedly, extracting the elements along the way, and finally disposing the enumerator. And they can be produced with iterators<\/em>: Methods that yield return<\/code> their elements as they are being asked for by a consumer.<\/p>\nasync<\/code> and await<\/code> were added to C# to deal with results that are not<\/em> necessarily ready when you ask for them. They can be asynchronously await<\/code>ed, and the thread can go do other stuff until they become available. But that works only for single values, not sequences that are gradually and asynchronously produced over time, such as for instance measurements from an IoT sensor or streaming data from a service. Asynchronous streams bring async and enumerables together in C#! Let’s see how, by gradually “async’ifying” our current program.<\/p>\nusing<\/code> directive at the top of the file:<\/p>\nusing System.Threading.Tasks;\n<\/pre>\n
GetNames<\/code> does some asynchronous work by adding an asynchronous delay before the name is yield return<\/code>ed:<\/p>\nawait Task.Delay(1000);\n yield return name;\n<\/pre>\n
await<\/code> in an async<\/code> method. So let’s make it async:<\/p>\nstatic async IEnumerable<string> GetNames()\n<\/pre>\n
Task<\/code> stuff: IAsyncEnumerable<T><\/code>. This is our async version of IEnumerable<T><\/code><\/em>! Let’s return that:<\/p>\nstatic async IAsyncEnumerable<string> GetNames()\n<\/pre>\n
GetNames<\/code> to GetNamesAsync<\/code>.<\/p>\nstatic async IAsyncEnumerable<string> GetNamesAsync()\n<\/pre>\n
Main<\/code> method:<\/p>\nforeach (var name in GetNamesAsync())\n<\/pre>\n
IAsyncEnumerable<T><\/code>. That’s because foreach’ing over asynchronous streams requires explicit use of the await<\/code> keyword:<\/p>\nawait foreach (var name in GetNamesAsync())\n<\/pre>\n
Main<\/code> method async. Fortunately C# 7.2 added support for that:<\/p>\nstatic async Task Main(string[] args)\n<\/pre>\n
Next steps<\/h2>\n