A Preview of C# 8 [video]

https://channel9.msdn.com/Blogs/Seth-Juarez/A-Preview-of-C-8-with-Mads-Torgersen

by plurby • 9 years ago

125 98 9 years ago

channel9.msdn.com

Sir_Cmpwn• 9 years ago

Found a text reference: https://www.infoq.com/news/2017/08/CSharp-8

suzuki• 9 years ago

Glad to see this Dart feature appearing in C#:

  Asynchronous Streams

Now you can "yield" Task<T> (~ Future<T> in Dart) and construct LINQ chains in an asynchronous fashion. I hope it streamlines reactive programming greatly.

[1] Dart - Asynchronous Programming: Streams https://www.dartlang.org/tutorials/language/streams

[2] .NET Futures: Asynchronous Streams https://www.infoq.com/news/2017/05/async-streams

nxc18• 9 years ago

There's some interesting and controversial stuff in here. I am very excited about extension everything. I also like the new extension method syntax; much cleaner and a much clearer expression of intent.

bpicolo• 9 years ago

Feels like extensions tend to make it hard to find out what you need to import to make things work as intended. Maybe visual studio proper is better at inference for it? Will only autocomplete methods that are actually in scope as far as I can tell.

wvenable5• 9 years ago

It will only auto-complete methods that are in scope (the alternative would be a bit crazy) however Visual Studio is smart: if you type in a method you know exists you can press CTRL-. to get it to add the correct using statement to bring that extension method into scope.

talyian• 9 years ago

Compared to say Python, it does act a bit like importing free functions without explicitly naming them, but you do get the bonus of type-based dispatch and overloading.

    using System.Linq;
    foo.Select(x => bar);

    from itertools import *
    imap(foo, lambda x: bar)

TimTheTinker• 9 years ago

Correct, it can be maddening at times when you want to use LINQ methods but forgot to include System.Linq.

ijidak• 9 years ago

I'm curious what parts you feel are controversial? I don't disagree. I haven't looked it over yet. But sometimes I worry that C# is adding too many features to keep up with what's hot at the moment.

Lambdas vs nested functions is an example that comes to mind (during the Microsoft Build conference presentation of the feature, the presenters jokingly admitted that nested functions arose from Javascript's popularity).

I felt like the value-add of nested functions over lambdas, versus the growth of language complexity, was not great enough to add nested functions as a language feature. (Of course, that's just my opinion.)

But the bigger question is, what's the threshold where software and languages go from being "feature rich" to "bloated"? And are there cases in the past where the corporate stewards of a language have found that sweet spot?

C# has been a great language. I use it every day.

But it feels like the inevitable end game for this language, and maybe every language with corporate stewardship, is that the pressure to release new versions to "keep up with what's hot" eventually ends in the death of the technology by a thousands cuts (where, in this case, by cuts we mean unnecessary features).

(To be fair, the language stewards so far have been batting 900. They've generally done a great job at this so far.)

GordonS• 9 years ago

By 'nested functions' do you mean local functions? Another reason for them is that they can sometimes bring performance improvements over lambdas.

bouke• 9 years ago

Great to see these Swift features[1] appearing in C#:

* Nullable Reference Types This makes it so much easier to reason about references. I always found it strange that C# had nullability on value types, but not on reference types.

* Default Interface Implementations Inherit an interface, and get an implementation "for free". This makes for a very powerful way to define interfaces and default implementations.

* Extension Everything As noted in the video/text, the current syntax feels a bit weird -- having to use a static class.

[1]: Not saying these are exclusive to Swift, or Swift was the first to implement them.

dep_b9• 9 years ago

Swift extensions do not have the ability to add variables to the scope of the class they extend or into their own private scope. Perhaps because the compiler times would crash through the roof but I find it very limiting. I do use extensions in Swift but I prefer to factor out any code into it's own class once it needs to touch any kind of state.

perfectstorm• 9 years ago

In Obj-C extensions you can add variables with the help of Obj-C runtime.

judah• 9 years ago

In the video, Torgersen says the nullability feature was inspired by TypeScript. Torgersen says he consulted TypeScript creator Anders Heijlsberg to build the nullable reference feature.

As a heavy TypeScript user myself, it was easy to see the parallels between the designs: question mark nullability, the compiler-enforced nullability checks rather than runtime-enforced, "dammit operator" to override the compiler. All shared between TypeScript and C#.

I love this feature in TypeScript; it's help me find numerous bugs and helps me reason about my code. I'm looking forward to using it in C#.

thavalai• 9 years ago

Just wanted to point out that besides creating Typescript, Anders has been the Lead Architect on C# since 2000.

nickspag3• 9 years ago

I am so, so excited for Default Interface Implementations. Abstract classes are great but when you want (have) to go down a different inheritance tree this will be so nice.

c0wb0yc0d3r• 9 years ago

With the introduction of this feature, is that the only difference between the two?

wvenable5• 9 years ago

I always found it strange that C# had nullability on value types, but not on reference types

Version 1.0 of C# was the same as Java: Nullable reference types and non-nullable value types. Nullable value types didn't come until version 2.0 but at that point ir was too late to make reference typed non-nullable.

I'm glad they're actually putting the effort to fix this issue now. It's a huge task given the amount of legacy code out there.

bernadus_edwin3• 9 years ago

Nullable reference without "if let" keyword is disaster

hungerstrike• 9 years ago

"If let" leads to code that is hard to read IMO. I'd rather be able to easily tell the difference between conditional statements and assignments.

Another Swift feature that I think leads to very poor readability is trailing closures.

MadsTorgersen4• 9 years ago

"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.

wuzzard• 9 years ago

C# 7.0 already has the 'is' pattern matching operator that returns true/false and can introduce a new variable that is not null.

zerr• 9 years ago

Default Interface Implementations

So basically multiple inheritance?

sandyarmstrong• 9 years ago

Except for state...

aardvark179• 9 years ago

For method lookup, but not for object structure. That's really important from an implementation viewpoint because field accesses can just be done as a simple offset without any complexity round the type.

jaredpar2• 9 years ago

It's multiple inheritance of behavior, but not of state.

dep_b9• 9 years ago

I'll crank up those `null` assignments to non-optional references warnings up to compiler errors. There's really no reason to ship software that doesn't explicitly declare something as nullable.

The `!`'s are always code smells. I hope I can turn them into warnings or build errors.

taco_emoji• 9 years ago

I wouldn't say they're always code smells. Like they say in the video, a call to the 'myString.IsNullOrEmpty()' extension method is a null check, but there's no way to prove that to the compiler.

dep_b9• 9 years ago

I think that's more of a compiler problem then. Also what's missing is the unwrap syntax to easily transform between nullable and non-null references. What you really want is to operate on a non-null version of that reference if it's proven to be non-null, this is really the Achilles heel of this particular implementation. You're still checking for null all over the place, it's just better checked.

    // Unholy mix of Swift and C# syntax ahead!
    if var unwrappedString = wrappedString && unwrappedString != "" {
         unwrappedString.Length();
    }

Where the `if var unwrappedString = wrappedString` part would unwrap the var and return a `bool` at the same time which is `true` if it wasn't `nil`.

Swift's nil-checking / unwrapping syntax is really short and with some clever usage of `map` or `flatMap` you can still have one-liners albeit a bit more verbose - but much more secure.

Example of using map:

    let myTitle = myObject?.title.map { "Item \($0)" } ?? "No title"

This code can't even theoretically crash anymore and doesn't force unwrapping with `!` as a traditional approach would do:

    let myTitle = myObject?.title != nil ? "Item \(myObject!.title!)" : "No title"

int_19h7• 9 years ago

The reason is that you have millions of lines of existing code written with "nullable by default" assumption in effect, and you need to be able to gradually migrate that.

dep_b9• 9 years ago

I think ReSharper already warns about a lot of those so if you've followed up on those warnings already you're in a good shape to switch to compiler errors. I don't think it'll take a long time to fix all new warnings even on larger projects. But the gains are huge.

_rmt_• 9 years ago

This looks great. I just stepped back into java for a one off project, after not touching it for about 15 years. I was surprised how antiquated it felt compared to modern C#. Glad to see Microsoft is not letting the language languish.

dep_b9• 9 years ago

Oracle basically destroyed every cool technology they inherited.

pjmlp8• 9 years ago

So far they have improved Java much more than Sun ever cared to do on its last years.

severino• 9 years ago

I know everybody hates Oracle here, but Java 7, 8 and the upcoming 9 releases, all of them under Oracle's control, have had more improvements than Sun did in the years prior to the acquisition. How's that destroying anything?

wvenable5• 9 years ago

The only time Java was cool was in 1995. But almost right off the bat, the language was ruined by an incredible desire to not even potentially break or change anything -- this is what got us inner classes for event handling -- and every design decision since.

If anything, Java (the language) is probably improving at a faster rate now than ever before but much of the damage is already done.

issaria• 9 years ago

Come on, default method in interface is a Java 8 feature, what's the coolness of C#is there?

pjmlp8• 9 years ago

Java is not designed by a single company, in spite of Oracle's stewardship.

And it runs in many systems that .NET still doesn't, so adding features without doing a Python 3 is very important.

eighthnate• 9 years ago

C# 7 was release a few months ago. The video is just a prototype of what C# 8 could have.

pjmlp8• 9 years ago

The current version is 7.1 already.

daxfohl3• 9 years ago

Would "extension interfaces" be equivalent to "type classes" in Haskell and/or "traits" in Scala or Rust?

joostdevries2• 9 years ago

Being able to take an instance Person and make it be an Employee without changes to the Person class definitely sounds like ad hoc polymorphism. In Scala the equivalent of Haskells type classes is implicits though. Not traits. I do wonder if this 'extension interface implementation' feature would support the same inferencing that type classes in Haskell and implicits in Scala do. So that might be a difference.

daxfohl3• 9 years ago

In Scala the equivalent of Haskells type classes is implicits though. Not traits.

Really? I'm not an expert but everything I've read until this implies the opposite. Besides, C# already has implicit conversions, and they're different from type classes in that they convert, not extend. Once an int is implicitly converted to a double, it's always a double from within the function that converted it, not just "representing" a double. So strictly less powerful than polymorphism. My understanding that type classes were the way out of that, and traits were Scala's equivalent. Is that not correct?

MadsTorgersen4• 9 years ago

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.

joostdevries2• 9 years ago

Interesting, the new type IAsyncEnumerable is like an Observable. But it's pull instead of push. Ie it supports backpressure like the Reactive Streams [1] standard in the JVM world. I seem to recall that Erik Meijer had some strong opinions when that standard was forming on backpressure and anything that's not purely push based.

Personally as a developer I really like having the choice whether to buffer in one place in my system (using a persistent queue f.i.) and have the rest of the system cooperate in tandem without running out of memory f.i. Or to choose to ignore elements when stuff is just going to fast. Etc. I feel more in control of the behaviour under load of my system.

I guess Lightbend was onto something when they took the old EAI notion of backpressure (as f.i. described in Gregor Hohpes book) and implemented it in stream processing and started an interoperability standard around it.

[1] http://www.reactive-streams.org/

zwieback• 9 years ago

Why is default interface implementation controversial? I get it for moving existing .Net functionality around but for development of new code, what's the downside.

Coming from C++ it seemed like C# interfaces (and Java at the time) felt like a punishment. Now I'm sort of used to them.

int_19h7• 9 years ago

It requires runtime (VM) support. That's always a much higher bar to clear than pure language features.

ajennings8• 9 years ago

Very excited about the Nullable Reference Types.

Besides that, the feature I want most in C# is enum exhaustion checking. So I can write:

  enum Color { red, green, blue };
  public static string SuperheroFromColor(Color c)
  {
    if (c == Color.red)
    {
      return "Superman";
    }
    else if (c == Color.green)
    {
      return "Green Lantern";
    }
    else if (c == Color.blue)
    {
      return "Spiderman";
    }
  }

and not get a compiler error (that not all code paths return a value). But if I added "yellow" as an enum option, then I would get a compiler error. I realize that Color can be cast from an out-of-range int, so it's a little complicated. I'm willing to put something extra after the last else:

  unreachable return null;

or use a special switch statement. I just want something so the compiler checks that I have accounted for all normal enum values.

Is anyone talking about such a feature, or where would I request it? Can I write it myself as a Roslyn extension?

opmac• 9 years ago

Kotlin has been doing null safety since release. I suggest checking it out if that sort of thing excites you. It's probably my favorite language currently.

UnoriginalGuy• 9 years ago

You're asking for a language change to fix poorly written code. The final else if() is redundant, if you change it to a simple else you remove the "not all code paths return a value" issue and remove a redundant check. This requires you to consider the "and others" possibility, rather than the compiler making assumptions about the type's definition.

Plus what you're asking for is a maintenance nightmare; since changing the type (Color) in one part of the code can break method definitions in another part of the code (inc. other assemblies).

I'd hope they would never support what you're asking for.

chowells• 9 years ago

He's asking for exhaustiveness checking of pattern matching algebraic data types. Many languages have had this for essentially forever.

It does sometimes mean that when you update some code, you have to update a bunch of other things. But it's rarely spurious. Usually those other things are broken by failing to consider the new possibility.

In the long term, it's a maintenance win.

parenthephobia• 9 years ago

By turning the "else if" into an "if" you introduce a silent bug when Color.yellow is added, since the final else clause would now have to deal with both blue and yellow correctly.

Adding a new member to the Color enum should break code that isn't written to handle it: which is any code written before Color.yellow was introduced.

ajennings8• 9 years ago

If I add a "yellow" option to the enum, then I _want_ to get compiler errors (or warnings) about all the places in my code that need to handle that new case. That's what compilers are for, that kind of busy work.

Is there a way to write that SuperheroFromColor function so that I will get a compiler error (or warning) if another option is added to the enum? (Imagine that function is far away from the Color definition so it's not visually obvious.)

When I create an enum with three possible values, I reason about it as having only three possible values. As long as I never cast from an int, that should be true, right? So I don't want to consider the "and others" possibility. It's hard to even think about what to do in that situation, since it shouldn't happen.

I said that I'm willing to put some keyword before or after the if statement to tell the compiler to make sure I'm handling all valid enum values. So it can only give me these errors (or warnings) when I ask for them.

I think pattern matching in Haskell will make sure you handle all possible cases and give you a compiler error if you don't. I'm asking for a "poor-man's version of pattern matching for enums" in C#.

wvenable5• 9 years ago

Use the switch statement without a default clause. If you haven't exhausted the options, you get an error.

ajennings8• 9 years ago

A compile-time error?

It doesn't do that for me on VS2012 or in .NET Fiddle: https://dotnetfiddle.net/f4NSvf

jaredpar2• 9 years ago

There is a proposal for "sealed enums" on the C# language repo that have the semantics you are looking for.

https://github.com/dotnet/csharplang/issues/782

khaledh• 9 years ago

I know this doesn't solve your problem in C#, but F# gives you a compiler warning in such a case. The following code compiles without warnings or errors:

  type Color = Red | Green | Blue
  
  let superheroFromColor c =
      match c with
      | Red -> "Superman"
      | Green -> "Green Lantern"
      | Blue -> "Spiderman"

However, if you add Yellow as a new case to the Color discriminated union without adding a corresponding match pattern everywhere you match a Color value, you get a compiler warning:

  type Color = Red | Green | Blue | Yellow
  
  ...
  
      match c with
  ----------^
  warning FS0025: Incomplete pattern matches on this expression. For example, the value 'Yellow' may indicate a case not covered by the pattern(s).

Aside: notice how terse and readable the code is compared to the C# equivalent; F# tends to have a high signal-to-noise ratio.

ajennings8• 9 years ago

I wrote myself a compiler extension to check this for me:

https://github.com/abjennings/EnumAnalyzer

SimonPStevens2• 9 years ago

I feel like I've been waiting for non-nullable reference types for forever.

What they talk about here, with explicit nullable reference types is so close but stumbles at the last hurdle. Having some kind of opt in on the compiler that makes regular references non-nullable is great for new projects (and arguably the best thing for the language itself), but leaves all legacy code out in the dark. You can't switch on a compiler option like this on any big existing project without massive effort. (And massive effort means management approval and planning and justification)

They got the case by case opt on the wrong part of the feature. It's really the non-nullability of a reference that's most important to be able to be opted in to on a case by case basis. (And case by case opt in means low effort, so it doesn't need big up front approval or planning, you just get on and write better code with fewer bugs.)

What's really needed is something like this

    String! s = null;

Where the ! makes the s reference non-nullable, so any attempt to assign null (or anything that could be null) to it is a compiler error.

And it's so disappointing because he comes so so close to that at the end with his talk of s!. as a way to say that you know something is not null, but it just doesnt quite get the benefit right.

It's non-nullability of reference types that should be the central feature here.

I'm just really hoping that these guys know what they are doing, and it's just he couldn't explain the subtleties in a short video, and this is going to turn out working the right way in the end.

ajennings8• 9 years ago

You make a good point, although personally my codebase is split into enough projects that I think the transition will be manageable.

If it's just a compiler warning (and you don't treat warnings as errors) then can't you leave it on and do the work gradually? Or turn it on for a day, do some work, and turn it off again? You have to eat the elephant somehow.

Also, even if you make the non-nullability opt-in on a case-by-case basis, don't you still need a compiler switch to turn on occasionally and see what remains to be done?

int_19h7• 9 years ago

The problem with that approach is that if you have it there, people will forget to use it, and still end up with tons of nullable references that really should be non-nullable. In order to be effective at catching bugs, non-nullability has to be opt-out rather than opt-in.

Yes, this sucks for existing code. I suspect that we'll get some kind of file-level switch, so that you can port things one class at a time - there's no reason why that switch has to have the same value for all files in the project.

SimonPStevens2• 9 years ago

No reason why there can't be both. Syntax to opt in one at a time for old projects, and a compiler option for new projects.

Yeah, or a file level switch would do, that would be fine. As long as there is some way of transitioning a project little bit at a time.

I hope we get one of those options

MadsTorgersen4• 9 years ago

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.

A Preview of C# 8 [video]

Related Stories