Via belle, via lul. Come on. OK, let's do this in English. I promise. And we all pretend we understand each other in Scandinavia. But sometimes things go wrong. So let's do this in English.

My name is Mes Torjusen. And I'm from Denmark. I know that this is the first time slot after the party. So I'll try to shout and make things really uncomfortable for you. Actually, if you could experience

the bright light that's coming into my eyes, you would wish you had gone home early last night. And it probably helps a little that you had to pay for the beer, but still. So I work for Microsoft. It says there on the slide, so it must be true. I'm on the C Sharp team. I help evolve the language. So what keeps me off the street, essentially,

is to always come up with more stuff to put into that poor little language. And that's what we're going to talk about today. So I can't really see you because of the bright spots, but I'm going to try this anyway. How many people here are .NET developers? OK, a few. Can we try this the other way?

How many are not? A very tiny few. And all the people who are asleep, maybe. OK, all right. Then I'm not going to try to convince you that .NET is a great thing, because you already believe that, apart from the two of you. And you're expendable.

So given that you're here and not at the HoloLens presentation, I will assume that you have a little bit of a hangover and didn't want the 3D kind of getting you sick. I'm going to try to show some data here on the assumption that you're too sleepy to see through it.

C Sharp is actually doing pretty well. So Stack Overflow, they do a developer survey every year of Stack Overflow people. So it's always skewed to who's already on Stack Overflow. And different languages and technologies have varying degrees of that. But given that, C Sharp is doing pretty well.

It's one of the most used languages there. Not the most, but on the other hand, one of the ones above isn't a language, really. I'm not talking about JavaScript here. It's not a programming language at least, SQL, right? So doing pretty well there in terms of numbers of users, despite certain limitations in where C Sharp is usually used.

So we're pretty happy about that. And what I think really warms my heart is this next one, which is the most loved technologies. They ask people, given that you're already using this technology, would you like to continue using it? And we're on there. We're not near the top.

But we're on there. So we're both very used and a pretty well-loved language as well. We're kind of proud of that. There's only these three down here that are actually on both lists. Either a lot of people use you or a lot of people love you. It's kind of weird that way. But we're kind of doing both. So we must be doing something right here. And we keep trying to think about what is it

that we're doing right and how can we prevent ourselves from stopping doing it, so to speak. That was a lot of negatives. Let's just give a shout out to F Sharp. It's high on the list as well there. So what is it that we're doing right? Well, we think some of it is we've sort of been lucky striking the right balance in evolving

the language. C Sharp is not a young language anymore. It started in the Java ages. Of course, it was a completely different language than Java from the outset. Any similarity was accidental. And so how can you keep a language like that relevant?

And how can you keep it going? What's the best way to keep it going, given that it has a lot of uses already? And so we kind of have this sort of a balancing act there that we try to keep our balance on. On the one hand, we want to keep improving it. The world of programming languages is evolving.

There's lots of fancy stuff that people can do in languages now that they couldn't when we came out. So we want to improve and be a good language as well. But at the same time, we can't take out what's there because then we're going to break a bunch of people who are already using it. And we want to also stay simple.

So we kind of have to be really careful about what we choose to add and make sure that when we add something to the language, it's really worth it. Every time we do, it gets bigger. We get further away from simplicity. And we can never get closer to simplicity again. Also, there's sort of a balancing act between people who are already, like most of you, who are already invested.

We want to improve your experience. And therefore, we kind of have to take your scenarios, the places where you're using C-sharp, we kind of have to take those to heart and improve incrementally in those areas. But at the same time, we want to be a language. We're ambitious. We want to be a language that people choose and pick up. We don't want to just hold on to our current community

and just go from there. We also want to invite new people in. So we have to also be attractive to new users. And how do we do that? And then there's the whole, like, a lot of the evolution in programming languages in general involves different paradigms than from where we started.

So there's a lot of functional programming going on. And we want to embrace that thinking. And you'll see some of that in the talk. And at the same time, we have to stay true to the spirit of the language. We have to make sure that it still feels like C-sharp. So it's a whole lot of taking these ideas but working on them until they fit, making them fit well into C-sharp.

That's sort of our job there. So I hope that gives you a glimpse into the forces that affect my everyday life, not that you care about my everyday life. But now there it is. So a lot of things have changed in .NET recently. Probably most of you have noticed some of it.

And I think it's really exciting. I think we're really expanding our opportunity in many ways. Of course, a big one is that it used to be that .NET was primarily at least a Windows technology. And that is really changing. We've done several things. We've embraced Samarin, which is all about targeting

all the big mobile platforms with C-sharp and with a lot of source code sharing, like with the vast majority of your source code being shared across. So that's a value proposition for any language. They so happen to have done it in C-sharp, and that's really, really super lucky for us. So now C-sharp on every mobile device, even Windows Phone.

Oh, it was there all the time. And also, we started this big project called .NET Core, which is about getting really good .NET, like modern .NET on Mac and most importantly on Linux.

So you can do your server jobs in C-sharp, run them really efficiently on other platforms. The other sort of architectural changes come along with that, like .NET, today's, in traditional .NET, it's sort of a system component. So there's all this, we have to worry about which

one is installed in your operating system and so on. And with .NET Core, you can just deploy the .NET runtime with the app, and it always works, right? We're making headway in compiling, actually, C-sharp to native code, compiling IL to native code. And so there are some performance improvements

there in certain scenarios. If you're willing to take the trade-off of compiling for a specific machine architecture, and you have a good deployment story for that, such as an app store, then that technology, I think, will improve over time and become an option for many of you. Sort of more on the developer side, if you will, it used to be that the compilers, the stuff that

understood C-sharp was just this black box, right? You just run the compiler, and it either gives you some errors, or if you're really lucky, it gives you a runnable program. And we've completely, completely changed the story there. What many of you have heard of is Project Roslyn. I'm going to touch a little more on that. So that now, the logic that understands C-sharp

is now an open API that everybody can rely on. And actually, I do want to call out, at this conference, many of you maybe were at talks that talked about .NET Core and Samurai in the previous days.

Today, there's a talk about one third-party framework that is using, that's built on top of this Project Roslyn, on top of this open API, so really opening up the ecosystem for language tooling, if you will. There's also one on the show floor down there, OSCode, which is an enhanced debugging

experience based on Roslyn. So it's really kind of starting to take root as a way that, a booster, if you will, for our language-based tools to go on them and have a much improved experience. Used to be that C-sharp and Visual Studio were joined at the hip.

We still kind of are a little bit, but the advent of Roslyn actually means that we've decoupled the editor-level understanding of C-sharp from Visual Studio in a major way, so that we are now seeing C-sharp supported in many, many editors, not just the Microsoft ones.

There's a project called OmniSharp, which is specifically taking the Roslyn language engine and targeting it to a bunch of different editors from Emacs through Atom and Sublime and all over the place. So we're kind of breaking out of that particular Microsoft

tie-in as well. And of course, the big one, we're now open source. OK, .NET is open source. We get contributions, like people fix bugs and add features to C-sharp and to the .NET stack. And it's really, really awesome. We had a whole port of .NET that was done as a third-party contribution.

So it's much easier for people to see what we're doing. It's much easier for us to get feedback, to get improvements incrementally. So we really, really love being open source. I don't know why we were so scared of it before, but we all get smarter. OK, so these last three ones are sort of the ones that are closest to what I'm working on

and the ones that are the background for this talk to come. But just keep those in mind as the .NET landscape really changing. So speaking a little more about that Roslyn project, the idea here is that there really should only need to be one code base in the whole world that understands C-sharp. OK, if we can do a good job, we

can build something that will satisfy all your needs when it comes to understanding C-sharp. Offer it up as an API, and it will be efficient in all your scenarios and so on. That is really, really hard to achieve, but we kind of did. It just took us a very long time. So we started talking about this probably seven years ago.

And it's out now. It came out last summer. And it kind of does what we wanted it to, so we're pretty happy. So as I said, it underlies all the IDs and editors. You want an Eclipse plug-in, fine. It will support that. Any kind of analysis tool, linter, code quality thing

that runs sort of offline, you can do that. If you want to do incremental stuff in the editor, you can add your own. We have a framework for adding what we call analyzers and fixers, and you can build your own refactorings really, really easily. I'm not going to show it today, but there's a beautiful full fidelity language model in the API where you can just

talk about the code as an object model. And it's really easy to build your own little tooling and click it into Visual Studio to other things that are starting to understand these analyzers and fixers. So in a sense, it's kind of actually taking the language experience to a new level. And I think we're sort of leading

the way a little bit for other languages in creating an open ecosystem around the tooling for the language that everybody can plug into. I think we can, with a little bit of luck and with your help, building some tooling around the language and sharing it out, we're actually on track for being one of the most magnificently tooled

languages in the world. I'm boasting a little bit here. I shouldn't do that. I'm in Scandinavia. Source generation, you want to build your own source code. Beautifully factored. Do it with Arslane. Scripting, REPLs, I'm going to show the REPL, the Redevelop Print Loop, in a bit. Oh, and it does compile too, right?

It actually will produce IL if you really want to. So really quickly, another thing that's sort of happening is that we're becoming more agile, becoming more decoupled from the Visual Studio cycle. And so I think we're moving to evolving the language

in a sort of more incremental, maybe faster, fashion. So C Sharp 7 is already imminent. We just released C Sharp 6 last year. That's increasing the cadence quite a bit over what we've been doing in previous years. C Sharp 8 probably won't be that far after. And we've been talking about maybe having point releases in between, where whenever we're finished with a feature,

why not ship it, yank up the dot number of the release, and let people use it if they want to, right? So it's something you can opt into. Well, we agreed across my organization that we will use C Sharp 7.3. And you can take that churn if you want to.

And I'm going to show you stuff from C Sharp 6, C Sharp 7, and C Sharp 8 today. So why don't I go ahead and do that? Stop talking and show us some code, right? Who's asleep?

No one anymore. Let's see. What am I doing? Here we go. OK. So let's start out. How many people have used the REPL yet? The C Sharp interactive window? Not enough. Actually, how many people are using Visual Studio 2015?

Oh my god, you're cheating yourself. Do you have update one? Or better? Yeah? Yeah, most? Come on, guys. Look at this. View the windows. OK. But it's there. You should go into other windows sometimes. It's not that stuff is less important. It was added later, and there wasn't room in the big one.

Look at here. C Sharp interactive. There's also a Visual Basic interactive. That's actually kind of a surprise to me. I hadn't seen that before. But let's do this one. It says C Sharp in the title of the talk. OK. This is an interactive window. It's like, do you know REPLs? OK. You type some code, it gets executed for you.

I type 3. Let's do something advanced. 2 plus 2. Hit Enter. And compile. Think about it. It's warming up a little. But hey, it calculates it for me. This is a calculator. Great. But it's also running C Sharp interactively. So I can define a variable. Let's define a variable like this.

Yeah. And now I can say Noria. And I say Noria, and you say Noria.

Only the Norwegians get this. So let's write some code. We can show some of the C Sharp 6 features here. Actually, already, the REPL comes with a using static. So a lot of people have seen C Sharp 6.

Maybe a lot of you haven't yet. It looked like about half and half. I'm just going to show a few features from there. C Sharp 6 had a lot of like features to reduce boilerplate. And so I'm going to show three or four of them. So using static is nice. It's where you specify a type instead, like system.console. And then all the static members of that type are put into scope.

This is a catch-up feature for us. Java has had this for like 10 years. And we're like, OK, let's do it. And it's actually great. That means I can just say right line. Right line. Right there. Right line is a static member of that type. It's now in scope. Great. The other thing, I mean, you use it for things like system.math.

I don't want to say math.sign, math.square root, blah, blah, blah, blah, blah. Other languages have done this for years. Now we can do it. So we can right line there. Let's right line an interpolated string. How many people have seen interpolated strings? OK, about half.

Also a thing that other languages are starting to have, ours are better. Interpolated string is a weird name that sort of just became, like many things have weird names like lambda. We just go with the flow here. So we can say, hey, and then put a hole in our interpolated string and say, no, yeah. And when we execute that, it's going

to take the value that was a value. This is just an expression in here. Many languages, you can only put a variable or something to something. You can put any old expression in C sharp here. I don't know what's up with their parsers. Like we're, we can put whatever big expression in here

and it gets evaluated and the result gets substituted in. It's nothing deep. OK, let's take that and put it inside of a method. So let's define a little method. Let's call it void greet. And then this has a very simple method body consisting of just an expression. So let's use expression body members.

A new thing in C sharp as well. If your method body or property getter body was just a return and then some expression, then get rid of the boilerplate and just put this function arrow here known from lambdas, popular from TV.

And just stick that there and you have to find a method. So when I say greet, it says that. OK, no surprise. Let's do one more thing. Oh yeah, nameof. Strange little feature but surprisingly useful.

So nameof, all it does is to take the name of something and give it back as a string. So that's pretty lame. Except the good thing about it is it only works if there is a something of that name. Why is that a good thing? Well, when you're printing out, throwing an exception

and putting the argument name in there, when you're using reflection or something like that and you actually need the name of a thing, and then you make a refactoring and the name of that thing changes but your little string literal didn't and you have a subtle bug in your code. Well, for all those cases now use nameof, it's a longer string literal and it gives more errors.

That's great. You want this, OK? So now I can say nameof here instead and it's no longer going to be Nynorsk. It's going to be Bogmår because that was the name of the variable, right? I can only do this demo in no way.

You should really appreciate this thing. So is that it? No, let's do one more. Let's see what time we have. We can do this. Let's say that, what do we do?

Yeah, let's go back up and declare the method like this again. So if I, let's say nor is null, don't try this at home. Let's say it goes away, right? It probably says in your national anthem somewhere, never shall no way perish or something like that.

Just for a second, let's just say it's hidden in fog. So I might want to write something that is, I might want to take advantage of it, not being null. So let's say that I want to print out,

I have code somewhere that takes the length of no way. That's about, what is it, 2,000 kilometers or something crazy like that? So it's actually an error right now, because no way is hidden in fog. If I wanted to be on the safe side and say, give me the length of no way if it isn't hidden by fog,

I can use the question, the null conditional operator, the question mark here, which will let you, well, it still goes wrong. Oh, only as I'm getting the wrong error here. Let's say, right line that thing. Let's go here.

Let's right line the thing. I was not, we can do it easier. Let's just remove the semicolon here. So I'm getting the value of that. It's not a null reference exception. The null conditional operator, sorry, I botched it a little. The null conditional operator will look at the left-hand side of a dot or an indexing or something, and if that's null,

it just won't do the rest. It'll just return null instead. So it prevents you from getting a null reference exception, which is the error I should have gotten before when I did this thing here. You see, still get that. Come on. There it is. There we are. Object reference not set to an instance of an object. OK, so the null conditional operator kind of

checks for null for you. So when you have all that code flow where you say, if that thing is not null, and if that thing dot the other thing is null, and that thing is null, and so on, you can kind of just compact all that back to saying, first thing, question dot, second thing, question, index, third thing. And then either that whole thing

will be null if there was a null along the way, or you actually get the value out. And then you can just check for null at the end. OK, so that's C Sharp 6, just a selection of features. And you also saw the REPL in action here. So whenever you want to try a new API or play with something, play with some idea before you put it into a project and make real code out of it, you get really good kind of immediate response

feel from using the REPL. So you really should, even though this is not a tooling talk, use the REPL. OK, OK, enough of that. So that was C Sharp 6. Yeah, get on with it. C Sharp 7. OK, so I have a prototype here. Actually, you can get a pretty up-to-date prototype

by downloading the Preview 2 of Visual Studio 15. There's some black magic that you need to do in order to enable the new language features. There's a blog out there. You can search in a .net blog and get the tricks. We're looking into getting a better. We're actually pretty far along in setting up better tooling. You can install a v6 soon, a Visual Studio extension

and Visual Studio that will help you download the latest. And then when you click Send a Smile or whatever, we automatically get your feedback on the new language features. And so we really, the more of you, play with it and give us feedback saying, oh, this works in a stupid way or whatever. Actually, we get really happy. And you get the language you want because we listen to you, at least mostly.

So C Sharp 7, there's a bunch of features. Let me start with a small one just to get us warmed up here. So one odd thing at numbers, let's actually

say int array numbers equals. So we can put some numbers in there. If we, so just numbers in order, right? If I was teaching a kid or I, in other ways, wanted to very explicitly see the bits

and understand what I was doing, I would want to use binary literals. So we actually added binary literals to C Sharp. You can say 0B and you get your binary literals. Probably not super useful in most cases, but hey, sometimes you want to see that bit pattern. You put hex and you kind of have to remember E is, what is E? It's 14.

But what is it in a bit pattern? So we also have now, these guys can get pretty long. So there's also now digit separators in there. That's the underscore there. So you can put it in wherever you want. If you want to kind of group your binaries by threes or your hex by twos or bits, whatever, you can do it.

You can put as many in as you want. Actually, we don't judge. But just useful syntax stuff there. So that's quickly over with, just showing it to you there because I needed a list of numbers anyway for my next trick. So actually, what I want to do is I want to take these guys and I want to tally them.

So I want to tally my numbers. And what do I mean by that? Well, I want to go through that list and I want to add them up and I also want to count them. I want to add them and I want to count them. And that's what my tally method does when I've written it because it's not there yet. So let's generate it. Let's not have the private there.

So let's call these values. So I'm going to end up with both a sum and a count here. What should I return? Should I return the sum or should I return the count? What do you think? Both. Yes, right. That's the right answer.

Both. I'm just going to return an int and an int, right? Yeah? Cool. See? So I haven't actually done it yet. Let me do it. Return an int and an int. This only works for zero, but it's still a pretty good, cool feature.

So this is a tuple type, all right? It's a tuple type. That's a new thing, language supported in C Sharp. It means an int and an int here in this case. You could put other types there too, trust me. So they can be longer. Actually, in this particular version,

they can be seven long, because there's underlying types that are, you know, and they only go up to seven. But when the compiler gets a little smarter, it will, there's actually an eighth one that has an extra field in it called rest. And when the compiler gets a little smarter when we finish this feature, it

will just recursively put more tuples inside of the other ones to emulate. If you have a 19 tuple, it will be transparent from the language level, and the underlying types will just be nested. So tuples of arbitrary size, but if you have a 19 tuple in a return, you're probably in a bad place anyway. OK, let's see, so what can I do with my tuple?

So now you see I get an int coming back here, great. OK, what can I do with it? Let's use the write line and write something out, interpolate a string, you know what that is now. So we, let's say that the first one is the sum. So we put that in there, say t dot. What's there? Well, there's item one and item two.

OK, I can probably guess what those are. Item one is probably, let's say it's, go out on a limb here and say it's the first one. So we've got item two here as well, and this is a way to get at these guys. They are names, but they're not really nice names.

So let's give them better names, actually. Let's put some names in our tuple type. OK, this one's the sum, this one's the count. Now I don't have to worry about that or read the comments or something outrageous like that. It actually says right there, this is still allowed, the underlying names are still there, but now if I dot,

you see that the good names are also there, so I can dot in for the sum and I can dot in for the count. It means the same thing as item one and item two. So sum and count, and all of a sudden, it gets kind of readable. So that's cool. I know some people have used tuples before and they'll be like, especially if you tinker with a functional language

and you've gotten kind of arrogant like those guys, you'd be like, yeah, but what about deconstruction? And I'm going to, so this is my answer. We'll get there, but we're not quite there yet. Take that. So it's going to be possible in a later,

when actually we ship this, to say something like s, comma, c here. Like you're saying var a couple of variables and the tuple that comes back immediately gets split back out into multiple variables and you can just use those s and c variables in the following statements here. So that's also in the works.

But we think both kinds of access are useful and important, so we're going to allow both. So far so good. Let's actually go and implement this thing for real. So let's take this tuple and return the result instead and then declare the result to be this tuple. That's a good start.

And now we can accumulate into this tuple variable. So let's say for each of those numbers there, reach var v and values, do something. And the obvious and probably the most beautiful thing to do is to say r equals a new tuple created from the old one.

So actually, this tuple doesn't have names yet. Let's give it some better names. So you can also do that in tuple literals. It looks like when you have named parameters. In general, you notice, I'm just going on a tangent here,

notice this looks kind of like a parameter list. So we're really trying to get a symmetry in the syntax here. So it just feels like a parameter list going the other way. When you look at the method, you can see the list of what goes out and the list of what comes in. And similarly for the literals, they kind of look like argument lists.

You heard the difference between parameters and arguments at the party last night. Arguments, they're the things coming in and the parameters are where they come in. Let's get that straight. But anyway, so now I gave these names. And so that means that r now has an s and a c. Actually, also notice, I keep interrupting myself.

And notice I'm returning an r that has different names than the return type has. And we totally don't care about that. We don't want to be rigid about, oh, the names have to match or something like that. The names are just there to help you. They're not there to create artificial barriers between. Tuples are just defined by the types and the positions.

And the names are just a help. So I can say r.s here plus the value that came in. And r.c, the count, plus 1. And I just updated my tuple variable here with a new value. Is this going to lead to a bunch of little micro allocations that's going to make my app here less performant?

No, because tuples are actually structs. So they're not classes. Objects don't get allocated. When you create a tuple, they're just structs. So when I return a tuple, I don't have to worry about, oh, I'm allocating an object. Should I return a tuple, or is that too expensive? Should I use our parameters? It's not expensive. It's just a struct on the stack. It's no more expensive than passing parameters.

Just the values are right there in the stack. So don't worry about that. Another nice thing about it being a value type is that they are values. They get copied whenever they get passed. So you don't get any shared state through tuples, which means we can make them mutable

without worrying about concurrency. So tuples are actually mutable. And we get a lot of crap from the functional crowd over this. But tuples are mutable in C sharp, because why not? There's no danger in this. Trust me. So instead of doing it like this, I could actually go and say r.s plus equals the value,

like that. It's fine. I can even say r.c++, which is not a reference to C++. So I'm incrementing the individual fields of their actual fields. I could even take a ref to them, actually. Just a public field, public mutable field.

So retro. But there's no magic, right? It's not some encapsulated data structure. It's just your stuff right there, open and accessible. And you can do whatever you want with it. Enough of that. Let's go back to the more beautiful implementation though, since this kind of hurts my eyes a little bit,

to be honest. There we go. I should have deleted this in one go. Then I wouldn't have so much undoing to do. There we go. So that's tuples. One more thing to say about them. This really is a type. So it can be used as a type argument,

and wherever you use a type. So for instance, for async in C-sharp, which you all know, Yeah? I can return a task of a tuple, which async methods, it's even more bothersome to return multiple values

from async methods, because you can't have out parameters. But now it's not bothersome anymore. I just return a task of this tuple type, and then when I consume it, I can await that task, and I get a tuple out. Simple as that. The red squiggle is because it's not in an async method.

It actually does work. So that's useful. And another thing to know about tuples is that they have value semantics, like the hash code inequality between tuples is value based. It's based on what's inside, which is typically the case for structs.

And that means that you can use tuples as a key in a dictionary, for instance. So if you have multiple keys, if you want to key by name and age, you can do that just by having a normal dictionary where you instantiate the generic type with the tuple type as the key. Or if you want to have multiple things come out

when you look up in a dictionary, you just have tuples as the values of the dictionary. So they just work right for all those things. So I think another good scenario for tuples is for them to be used in data structures

in various places. Good? Yeah? Can you use? Cool. It's so great getting applause for things that were in languages 30 years ago, and we only finally got to it. I'll take it. Another thing, pattern matching.

So let's change the example a little bit. And it's a little contrived, but just bear with me. Small examples, easier on the stage. So let's say that we actually want our tally method to take recursive lists. So we're going to represent those by arrays that can contain either integers or other arrays that can contain either integers or other arrays.

So we're going to make it recursive. And I'm just going to take a total ugly shortcut here and just make it an object array. So I can contain both those things. So it's still fine to put all integers in there. But we could also put a nested array in there saying new object array of some of these guys here.

And just to make it a little more interesting, let's also put a null in there since it's now an object array. And now, of course, tally doesn't work anymore because it takes an int array. So we're going to change it to take an object array. And when we do that, of course, this bit doesn't work anymore because v, as we for each over the objects, is no longer known to be an int.

So how can we implement this method to do the right thing? Well, what we would do today is something. We have a few options, but something along the order of check if v is int, do this, do that thing down there.

But of course, we can't just do it because even though we just checked that v is int, it doesn't know that v is int down here. So we have to say it again. Oh, and if it's still int, do the addition. So we can do better than that, and we are. So think of this as just a small trick right now. If I declare a variable here, I put a variable name there,

what that means is I'm introducing a new variable, which is v as the int that we just checked it was. So if the is expression is true, then the i gets assigned to the value of v as an int. And now it's known to be an int, and I can just use it down here.

Kind of simple but useful. You all have code that does this, right? Except the two that don't use C sharp. You have similar code in Java, and you wish you had this now. So that's kind of cool. But what this really is, it's not just like an expansion of the is expression.

We're kind of edging into something new in C sharp. Int i here is really a new kind of thing in the language, which is typically called a pattern, like other languages call this a pattern. What a pattern is essentially it's something declarative that both checks something about a value, whether it's true or false,

and it also extracts some information. It can do either or both, extract some information from that value if the check is true. So this is a clean little example of that. It checks that it's an int, and it extracts the int value from it into a new variable. That's what patterns do. And there can be other patterns, and there will be other patterns in C sharp. Just probably not in C sharp 7.

But this is the beginning of a pattern, and you can use patterns in different places. So let's say that we want to also now deal with the case where v is not an int, but it's an object array. We could go on here and say else if, else if, and then we say v is object array, oh, and so on. And now we'll be checking things about,

we'll be saying v is a lot of times. So we are asking questions of v all the time. And there should be a better way of doing that than repeating ourselves so much. And so another place where we're integrating patterns into the existing language, this is that thing about keeping the spirit of C sharp while adding new things, is the switch statement.

So we can switch on v. And in C sharp, up until now, it hasn't been legal to switch on just anything. You can only switch on primitive types and stuff like that, primitive types and strings. You can now switch on anything you like.

So you see it's not an error to switch on v here. And then I can have cases. I can still say case five, but I can also now put, let's say, int i. OK, and IntelliSense doesn't quite work yet with these new features. Case int i. So I'm essentially applying the pattern here again.

And why am I getting a red squiggly? It's not because this isn't implemented yet. It's just because I forgot to put a break. So there we are. Let's indent this whole thing. So I can actually now put patterns in cases. So I now have type switching. I can say switch on this thing in the case where it's an int, call it i, and do this thing here.

So now let's do the same thing for object array. Let's call it l for list. I can now implement it for the object array that's called l. What we want to do is we want to recursively, let's get the nested result. Let's call it var n by calling tally on that list and get its numbers.

And then we add them into ours. So let's say r equals r.s plus the thing that just came back. So n is now a tuple that was returned by tally called recursively. So it has a sum in there.

And we do r.c plus the count from there. OK? You get the idea. So now we fixed that one as well. And we also need to put a break. We haven't fixed that yet. We talk about it. Do you think we should take the break away here and just let you do? Yeah? Yeah?

Yeah, a lot of people say that. Who thinks we shouldn't? She thinks we shouldn't. OK, a few. Yeah, right? Because then if we, let's say we had another case here. Now I say case five. Now it's fall through. Now it isn't. So it's kind of subtlety if we do that. But anyway, that's a sidetrack.

But OK, so I can put patterns in there. Let's say, just for the sake of the example, it's a little silly. But let's say we don't want to do this recursive calling and stuff if that array is empty anyway. It could be an empty array. So I can say, I can put another case there. Now it's complaining that I have two of the same.

But I can put an extra condition on there. So I can say, when l.length is 0, I want to do nothing. I just want to break, because I don't want to go into an empty array. So you can also put conditions in your case statements

now with the when clause here. What's the question? Does the order matter? Sure. So the thing about the switch statement up until now is that it doesn't have a concept of evaluation order. Because when you have constant cases and default,

when they're the only things you have, they're all independent. Now we have to introduce an evaluation order. And so they're evaluated from top to bottom, except the default, wherever it occurs, is always evaluated last. So now there's a top to bottom evaluation order and switches that wasn't there before, didn't need to be there before.

So in this case here, we'll get to this one first. And therefore, we know that when we get here, well, you know at least that l.length is not 0. It's just one of those things. It's similar to catch clauses, right? They also do a type check in order. And they also, since C sharp 6, I didn't show that.

But since C sharp 6, you can also put conditions on those. In a catch, you can actually say when and some condition. And then we'll catch only when that condition is true. So it's very, very similar. We try to keep it similar like that. OK. What else can we say? Oh, yeah, there was that null up there. We still have the constant cases.

You saw that before as well. So I can say case null. And I could also put a default that throws an exception. It's still the good old case statement that's just been extended now with more permissive types here and with more things you can do in the case clauses. So that's sort of the beginning of pattern matching,

is type matching really, that's coming into C sharp 7. You see yourself using that as well? Yeah? Cool, good. Then we're doing the right thing. All right, so I think I want to show one more thing in demo and then we go back to slides. Let's remove this curly brace here.

What I just did was I took the tally method and I put it inside of the preceding method. And that's getting me a surprisingly small amount of red here. So let's delete the static here now.

What I have now is a local method. So we're now allowing you to declare methods inside of other methods. The other red that I'm getting down here is that I'm missing a curly brace somewhere. There we go. Oh, and then I have a little bit of red up here saying that because tally is a local method, just like local variables, it can't be used before it's declared.

It's just complaining that I'm using it before I'm declaring it. So I kind of have to swap the order around here. I can take these couple of lines and move them down to the end if I can find the end. Boop, boop, boop, boop, boop. It's probably there, right? I hope so. Yeah, you see, now all the red goes away.

So I just declared it as a helper method inside of another method. So useful sometimes if you're, you know the feeling of declaring a helper method and you make it private, but you really don't want the other methods to take a dependency on it. Sometimes, like, I'm building an iterator or an async method and I don't actually want it to be an iterator or async.

The iterator, I want to check my arguments eagerly, so I kind of have a wrapper method that's a public one, and then it calls the iterator method. Now you can put the iterator method inside. And they share. You know, I carefully didn't use any same names. But of course, the names up here, numbers, is in scope down here. If I set numbers here instead, it would work the wrong way

because it'd keep going on the same way when I call recursively. But you can see that it's totally in scope and it's totally allowed. It's just like Lambdas. It captures enclosing variables and so on. And some languages, like JavaScript and other languages,

and also traditionally, like Pascal and so on, it's been actually a structuring mechanism for code to put methods inside methods inside methods, or procedures inside procedures inside procedures. Some people write their JavaScript code like that today and use that as the main scoping mechanism, the main composition mechanism.

And we're kind of getting to where, if that's how you roll, you can do that in C-sharp. So that may not be the most common case. But I think that just the helper method thing is useful. OK? And it's also more efficient than Lambdas. There's no allocation involved.

So that's it for demos. Let's go back to slides and talk a little bit more about the future. There are a few more things that I'm not going to get to that are in C-sharp 7 as well. But as I said, we're kind of upping the cadence of the language. And so we're trying to get comfortable with not just

starting any version of the language with a blank slate sitting down saying, OK, what should we do this time? And then we have a three-year thing to kind of get it all designed and implemented and shipped. And then we go blank slate again. We're trying to kind of work on multiple trains at a time. Well, this one is a little more difficult to figure out. So let's start working on it, but not

expect it to be in the following release. We have to get better at that. Like everyone else, we finally have to wake up to the reality that you can have multiple trains. And you can work on them at the same time. And the train leaves the station. You just get the train when you're ready, whichever train leaves the station then.

So I mentioned that there will be more kinds of patterns. And I don't think they will make it into C-sharp 7. But here's a, let's actually project. We get the full size of it. So this is what's there, right? You can check that an object is a point. Let's call it P. And P is now in scope. And you know it's a point.

So you can dot into its x. OK, great. I could also imagine doing this in different ways. Maybe there's a property pattern that digs in recursively and say, if O is a point, then take the x and call it and put it into a fresh variable, extract information, right? So check and extract. Those are the jobs of a pattern.

So extract that into a variable called x, and a fresh variable called x, and extract the y into a fresh variable called y. And then those are in scope in the following thing. Or you can imagine that point, that's a more terse positional way of extracting things. Point says, when you deconstruct me, like we talked about deconstruction for tools before, maybe point says, I can be deconstructed.

And when you do, the x is first and the y is second. And I can just use positions here to say, OK, I'm extracting whatever was capital X. Because whatever's in the first position, I'm extracting that into our x and that into our y. And of course, in case clauses,

you already have constants. So constants are sort of already patterns. And so instead of taking var x and then checking that it's equal to 5, maybe you can just put a 5 there, recursively, and say, this whole pattern only applies if o is a point where x is 5, and then take the y

and put it into a variable and do something with it. So we have much further we can go there if we want to, and if we can get it right. Another thing, C Sharp, for now soon seven releases, has not had a good sort of static compile time way of dealing with nulls.

You test, you get a null reference exception, you go, bummer. You fix your code. Hopefully you swatted all of them before it ships. This is one of those things where we're starting to look a little long in the tooth here, a little old, compared to some of the fancy new languages. They're probably going to die out in a couple years.

But mayflies, but they still move the state of the art. We kind of have to keep an eye on that. So a language like Swift, for instance, I'm not actually going to call Swift a mayfly. It's an awesome language. And they have a very deliberate handling of null. You can distinguish whether things can be null or not.

We want something like that as well. But for seven releases, we haven't had it. And so you can't just go and put a breaking change in the language and change everything. So that said, here's the kind of thing that we're thinking of. One thing we can never do is to build a feature that's 100% guaranteed, that can never be a null.

That ship has sailed, for sure. There are all kinds of reasons I'm not going to give you, but you can ask me later. But we do want you to be able to express your intent. When you declare a variable or declare anything with a type, we expect the syntax will be saying, this is actually supposed to sometimes be null. n is supposed to sometimes be null.

It's part of its domain. However, s here, not having a question mark, it's actually not supposed to be null. Once it's initialized and everything, it should never be null anymore. And then given those two things, we can try to enforce safe practices when programming around these. First step, express your intent. Be able to express your intent. Once you have syntax for that, then we can help you with warnings or maybe even errors

and help you do the right thing. Sure, I can assign null to n. But if I assign null to s, I'll get a warning. s should not be null. Don't do this. And of course, indirectly as well, don't assign a nullable to a non-nullable without a warning.

On the other hand, what you can do with s without fear is you can start dotting into it. You can dereference it. Because s is not supposed to be null. So of course, there might be edge cases where it still is null or something. Default value of any reference type in C sharp is null. So that's why I'm saying it's not 100% guaranteed.

But this is going to help you have a good discipline if you're not doing weird, quirky, edgy stuff. So it's fine to dereference it. It's not supposed to be null. But if you dereference n, we're going to say, you're dereferencing something that is supposed to sometimes be null. It says so in its declaration. So you probably have a bug right here.

Of course, in order to enforce that, we need to be able to recognize when you're checking for null. Now, when languages build this in from version one, they just introduce a specific way of checking for null. That the compiler then, typically, it introduces a new variable or something for that.

We can't introduce a new specific way of checking for null. There's already like seven ways of checking for null that I can think of in C-Sharp. So we have to, instead, recognize, through flow analysis of your source code, that we think you checked for null. So something like this, if this is your code, maybe you have the code today and you just went and put

question marks in there in order to improve your checking. We need to recognize that you've checked for null here. The compiler knows that even though it's declared to be nullable, in here it's not. So it's not going to complain about this. It saw your check. It's fine. So flow analysis is sort of a way of not introducing yet another way of checking for null.

Of course, sometimes you know it's not null. Because you know that whenever that enum over there was green, that other thing over here is never null. You just know that. It's part of your invariant. And in those cases, you get to insist. So we're introducing the bang operator.

We should probably call it something else. The exclamation mark operator, which an exclamation mark means, trust me, it's not null. If it tells the compiler, trust me. And we could call it the trust me operator. We're actually more inclined to call it the dammit operator. Do what I say.

Don't complain. So I think that's a very likely C Sharp 8 feature. And maybe even one of those that we can do in a point release before that. Sometimes, and this is again coming in from sort of other paradigms, sometimes the language

and its roots are perfect. You are object oriented, stateful, imperative. It's all great. Sometimes, it's just fighting you every step of the way. I want to have my objects be immutable. I want to have them have value semantics

so that when you compare them equal, it's by value, not by reference. And we're not very good at supporting immutable objects in C Sharp. We've gotten a little better. But it would be nice if we were even better. And one of the things we can do is make it easier to declare a class that says, hey, this guy is just a data object.

And you're not supposed to mutate it. You're supposed to create new ones from old ones if you want to change something. You want to use that immutable programming, non-destructive mutation kind of paradigm, sometimes just the right way of working with data.

And so we're thinking about adding syntax. Maybe it's going to look like this, where in a very concise form, you're declaring a class. And we're putting these just parens and some types of names. We're declaring a class that has public properties first and last of type string that are immutable. And the whole class has value equality.

And it's automatically got a deconstructor like we talked about before with point. And it's sort of just like a data object, if you will. So essentially, writing that essentially keeps you from having to write all that stuff. So something like that, we call it record types, might be the right kind of abbreviation

to introduce into the language to level the playing field between imperative mutation oriented programming and functional style immutable programming. So that's also on the agenda for a post C sharp 7 language. OK, so we have a few minutes for questions.

I hope you have some. And I also want to say that I'm going to go down to the Microsoft booth in the expo hall right after. So if you have more questions, just want to chat, I'm going to hang out there. I'm going to be there for as long as people show up to chat. Also, don't forget to press one of those buttons out there. I hear that the red is not working,

so don't bother pressing it. But the other ones, especially the green one's really good. This is my Twitter handle, tweet at me. And that's what I have. Thank you very much. Thank you.

So we have like two minutes left, so I'm going to hear if there are any questions. And maybe you should shout out, because I may not be able to see your hand. Questions, go. Don't be shy. Please, please don't be shy. Don't be shy, Norwegians. There.

How would you use a REPL to call into your own code? So you can use, you can, the REPL by default isn't tied to a project. But you can use it to, you can use it to simply, you can simply reference things from the REPL. It actually has a pound reference directive inside, where you can reference an assembly.

And that would be a way to do it. Yeah, unless you probably, the REPL, there's still, let's say there's a bright future for the REPL. Another way of saying it is it doesn't have all the functionality it probably should yet. Seeding a REPL from a project, I think, is not there yet.

But that's a, so you just automatically, you're in a project, you just say REPL from here or something. And it has all that context already to play with. I'm not sure if it's in yet, actually, and not in update 3. Hopefully, it's on its way. So that's one of the things we have on the dock there. Another thing that we imagine for the future is to unify the REPL and the immediate window

in the debugger so that you can use the REPL as you're debugging. You can already have an expression evaluated. You can already write an expression and have it evaluated in context of where you stopped in the debug session. It'd be great if you could also declare some helper methods, maybe pull them

in from script into the REPL window and maybe declare them on the fly there and use those as you're debugging and kind of looking around. So there's more that can be done. And hopefully, we'll get there. Otherwise, did I mention we're open source?

So if you want to add any improvements, go ahead. There's more to do than we can possibly do. So you can actually help vote with your feet. If you do something, that's great. We'll take it. OK, next question. We can take another one. There's one up there. I can totally not hear what you're saying.

Could you pre-declare inline methods? What do you mean pre-declare? Oh, so that you can see them before, declare them up top, and define them down bottom? Well, that's a good question. So we started out cautiously here in the prototype.

I think we still need to think a little bit more about it before we ship, saying that they have the same scope rules as local variables. The thing we have to worry about is that they can see local variables. And so if they can be called before they're declared, then you can call to something that can see a local variable that hasn't been initialized yet where you

called it from. So there's stuff like that that we need to figure out. But we have talked about it. So one problem is it kind of gets rigid where you have to declare them. Another problem is you can't have mutually recursive methods because the first one can't see the second one. The only way to have mutually recursive methods is to nest them inside of each other because then they

can both see each other, which is absurd. So there's something that isn't quite there yet. We may ship like this in C sharp 7 if we don't. And then we can loosen the rules later. That might be one way of attacking it. I see that we are now on time. So thanks again. And come see me at the Microsoft booth.

Thank you.