MadsTorgersen

At first we did think of this as a way to add non-nullable reference types to C#, maybe with a `string!` syntax as you propose.

The feature only really started to gel when we realized the important feature was nullable reference types. The thing is, in most code, most things aren't actually supposed to be null. So we want non-null to be the default.

When you start marking the things that should be null as such, you'll be protected from dereferencing those without a check. That's what actually prevents you from getting null-reference exceptions!

And once you've marked them all (usually a fraction of your type annotations), null really doesn't have a place in the remaining spots, and you can turn on the non-null check to eradicate those.

This leaves you with the smallest number of places to update your existing code, and leaves new code the cleanest.

There's a great proposal for adding type classes to C# here: https://github.com/MattWindsor91/roslyn/blob/master/concepts...

And I discuss some ways that could be integrated with the extension everything proposal here: https://github.com/dotnet/csharplang/issues/164

The problem with both is that there's a new notion of "shape" or "concept" that's different from interfaces. It would be nice to just use interfaces for this (which is what I hint at in the video), but that comes with its own downsides and limitations.

"If let" could be easily mirrored by a pattern in C#, and we are starting to discuss that.

However, that's a new way to check for null in the language, where what we need is to recognize the ways people are already checking for null in billions of lines of code. Therefore, the priority is to do a good flow analysis that will just understand when a nullable variable can be assumed to not be null (e.g. after a check, a non-null assignment, etc.), and then let you dereference without challenge.

For the past couple of years I have been the lead designer of C#. Anders and I took a break to help create TypeScript, and then he stayed on as it's lead designer, while I returned to take over C#.

Anders and I meet every week to compare notes, and I make sure to get his input on major new features in C#.

Hey, thanks! If they let me out of my cave again, I'll make a point of visiting more often!

BTW, as trolls go, the one who commented on the blog turned out to be comparatively sweet: After my response they came back to say they were really sorry, and asked that I delete their comment. Which I did, so you won't see it anymore.

#TrollsArePeopleToo :-)

Hey, I didn't write anything between the lines! :-)

Don't worry: We're not "handing F# over to the community"! It always had a strong community participation, and continues to. It's a fabulous collaboration. This post is not an attempt to signal a change to our strategy for F#, and if anything should be read as a commitment to F#.

We're currently integrating F# more deeply with Roslyn, which should lead to an awesome bump in tooling quality.

You're seeing us strike a balance here. As I point out in the post, there are millions of C# developers, and tens of thousands of F# developers.

However, we think F# has awesome growth potential, and is great for .NET in general. So while we can't defend spending the same resources on it as we do on C#, we want to do what it takes to nurture it and keep it healthy and growing.

Being on the inside at Microsoft over the past years, it's been great to see more and more of the organization think of F# as part of the family.