Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News C# 8.0 Previewed

C# 8.0 Previewed

Leia em Português

This item in japanese


In a Channel 9 video, Mads Torgersen has demonstrated the first four features for C# 8.

Nullable Reference Types

We’ve covered nullable reference types in the past, but briefly the idea is that reference types would no longer be nullable by default. Instead, you have to explicitly mark them as nullable using the same “Type?” syntax that you use for nullable value types.

Assigning a null to a non-nullable reference type will be a compiler warning. Likewise, reading from a nullable type would be a compiler warning unless the variable in question was explicitly checked for null ahead of time. So theoretically the only change developers need to make is to sprinkle question marks where appropriate.

Since our report, a new syntax was added to this feature. Consider a scenario where you know that the nullable variable x isn’t actually null, but you can’t prove that to the compiler. In this case you can use x!.Method() to suppress the compiler warning about potential null reference exceptions.

Async Streams (a.k.a. foreach async)

Async streams are the asynchronous equivalent of IEnumerable. As we reported before, async streams is something that they’ve been working on since 2015. After much debate the syntax they settled on is:

foreach await (string s in asyncStream)

When defining an async iterator, you would use this function signature:

async IAsyncEnumerable<T> MethodName()

As with normal IEnumerable methods, you can use “yield return” to build the stream of objects in a lazy fashion.

The benefit of using this instead of IObservable<T> from Reactive Extensions is that the consumer controls the flow rate. This is referred to as a “pull model”. By contrast, IObservable<T> is a “push model”, which means the producer can flood the consumer with a higher flow rate than it can handle.

Default Interface Implementations

Default interface implementations are essentially a limited form of multiple-inheritance. This will allow abstract interfaces to fully define methods just like abstract classes. However, abstract interfaces will still not be able to declare constructors or fields.

Note: You can simulate fields on an interface using ConditionalWeakTable.

The primary benefit of default interface implementations is that you may be able to add new methods to an existing interface without breaking backwards compatibility. This isn’t guaranteed, as it would only work when a suitable default method can be devised.

This is a very controversial feature. We won’t repeat the arguments for and against it here, but you can read a summary of them in our earlier article on default interface implementations.

Extension Everything

A long-time complaint about C# was that you could write extension methods, but not extension properties. In fact, there is no way to even define an extension property or event using the current pattern. Additionally, putting extension methods in static classes feels ‘weird’ to many people.

Under the new design, there is a new top-level construct called an “extension”. For example, if you want to create extension methods and properties for a Customer class you would write:

extension CustomerExt extends Customer {
    //methods and properties go here

As with interfaces, you cannot define instance fields in extensions but you can simulate them using ConditionalWeakTable. You can also define static fields.

In addition to properties, events, and operator overloads, they are even considering allowing extension constructors. Extension constructors would be very interesting in factory and object pooling scenarios.

Extension Interfaces

Extension interfaces, the ability to add new interfaces to existing classes, is also being considered. This would not be a C# 8 feature though, as it would require changes to the underlying runtime.

For more information about the future of C#, check out the C# Language Design Repo.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Too Fast

    by Timothy Liu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    When body goes too fast, it should wait a while for its soul.
    When C# goes too fast, it should wait a while for ... the document >_<

  • Re: Too Fast

    by Néstor Sánchez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    C# is just including features that other languages (mostly functional) already have (slowing the pace would put it a "javaesque" state). And yes, the dev team prefers to get the compiler first instead of the spec, but a succint description and good examples are good enough to understand and soon take advantage of the features. For me this means express more and better in less code.

  • Blog Post on the same

    by neel bhatt,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Nice one.

    I have written a blog post so that it can reach to many more people.

    It is here:

  • Less interfaces, more visuals

    by Átila Cunha,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    So, C# is on it's way to act and feel more and more like Visual Pascal aka Delphi, but more efficient, elegant, modern and complete.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p