Working with data
Today’s programs are connected and trade in rich, structured data: it’s what’s on the wire, it’s what apps and services produce, manipulate and consume.
Traditional object-oriented modeling is good for many things, but in many ways it deals rather poorly with this setup: it bunches functionality strongly with the data (through encapsulation), and often relies heavily on mutation of that state. It is "behavior-centric" instead of "data-centric".
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. Let’s continue being inspired by functional languages, and in particular other languages – F#, Scala, Swift – that aim to mix functional and object-oriented concepts as smoothly as possible.
Here are some possible C# features that belong under this theme:
pattern matching
tuples
"denotable" anonymous types
"records" - compact ways of describing shapes
working with common data structures (List/Dictionary)
extension members
slicing
immutability
structural typing/shapes?
// First class pattern example
var myPattern = #(x:1, x:2);
if (Point(1,2) # myPattern) { print("match"); }
n.b # is probably too overloaded - but you get the idea.
In general, the Built Collections are exactly what we need for our use case: collections that are part of a complex data model, e.g. things that will be displayed to and edited by the user, or sent/received by RPC.