Microsoft kicks off C# 7 language planning

The design team working on C# are examining data management, performance, and reliability for the next update

Designers are off and running with plans for the next generation of Microsoft's C# language, with key themes centering on data management, performance, and reliability.

According to meeting notes for the C# team, posted earlier this month on GitHub, the team is looking beyond the planned version 6.0 of the type-safe, object-oriented language. As posted by Microsoft's Mads Torgerson, a design team member, the notes say: "This is the first design meeting for the version of C# coming after C# 6. We shall colloquially refer to it as C# 7." Likely themes to investigate for C# 7 include working with data; performance, reliability, and interop; componentization, distribution, and meta programming.

In accordance with theme of working with data, possible C# features could include pattern matching, "denotable" anonymous types, working with common data structures, slicing, and immutability. The notes state that today's programs are connected and trade in rich, structured data -- what's on the wire, what applications and services produce, manipulate, and consume. Traditional object-oriented languages, while good for many tasks, deal poorly with this setup.

C# builders must look at functional languages to deal with this, the notes stress. "Functional programming languages are often better set up for this: data is immutable (representing information, not state), and is manipulated from the outside, using a freely growable and context-dependent set of functions, rather than a fixed set of built-in virtual methods," the notes say. C# followers need to keep being inspired by languages including F#, Scala, and Swift.

For performance, reliability, and interop, the team states that C# has had a history of being "fast and loose" in performance and reliability. "Internally at Microsoft there have been research projects to investigate options here. Some of the outcomes are now ripe to feed into the design of C# itself, while others can affect the .Net Framework, result in useful Roslyn analyzers, etc," Torgerson's notes say. "Over the coming months we will take several of these problems and ideas and see if we can find great ways of putting them in the hands of C# developers."

Concentrating on componentization, the notes state the "once set-in-stone issue of how .Net programs are factored and combined is now under rapid evolution." Most work in this space is more tooling-oriented, covering capabilities including the generation of reference assemblies, static linking, determinism, NuGet support and versioning. "This is a theme that shouldn't be driven primarily from the languages, but we should be open to support at the language level."

To help with the distributed nature of modern computing, C# designers are pondering async sequences and serialization. "We introduced single-value asynchrony in C# 5 but do not yet have a satisfactory approach to asynchronous sequences or streams." For serialization, "we may no longer be into directly providing built-in serialization but we need to make sure we make it reasonable to custom-serialize data -- even when it's immutable, and without requiring costly reflection."

Meta programming, meanwhile, has been "on the radar" for a long time, with the Roslyn compiler project intended to enable programs about writing programs. "However, at the language level we continue not to have a particularly good handle on meta programming."

The team is also considering null capabilities as a theme. "With null-conditional operators such as x?.y C# 6 starts down a path of more null-tolerant operations," the notes say. "You could certainly imagine taking that further to allow e.g. awaiting or foreach'ing null, etc. On top of that, there's a long-standing request for non-nullable reference types, where the type system helps you ensure that a value can't be null, and therefore is safe to access."

Also with C# 7, designers  are pondering pattern matching, providing a way of asking if a piece of data has a particular shape, then extracting pieces of it. Array slices, meanwhile, would boost efficiency by providing a "window."

"Array slices represent an interesting design dilemma between performance and usability. There is nothing about an array slice that is functionally different from an array: You can get its length and access its elements," notes state. "For all intents and purposes they are indistinguishable. So the best user experience would certainly be that slices just are arrays -- that they share the same type. That way, all the existing code that operates on arrays can work on slices too, without modification."

Design notes state that while input and openness is sought in the development of C#, ultimately, decisions are made by the design team. "It's important to note that the C# design team is still in charge of the language. This is not a democratic process. We derive immense value from comments and UserVoice votes, but in the end the governance model for C# is benevolent dictatorship."

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags Microsoftsoftwareapplication developmentC#GitHub

More about MicrosoftScala

Show Comments