Though after C# 4 (covariance and contravariance) and C# 5 (async/await) the evolvement of C# might have seemed to slow down a bit, the big picture hasn’t as shown in the [Wayback/Archive] Why is C# Evolving This Way? – YouTube video by Zoran Horvat which comes down to:
- Summing up all major changes between C# 1 and C# 12
- Grouping them by major aspects:
- Generics (covariance and contravariance, generic constraints, and covariant return types)
- Performance upgrades (expression trees, null-conditional, async/await, spans and async streams)
- Define behaviour in a functional model (ranges, extension methods, and many kinds of pattern matching)
- “Pure gold” (lambda expressions, expression-bodied methods, nullable references, init-only setters, lambda types, primary constructors, records and record structs) allowing all other aspects to be written in far more elegant ways
- Grouping them by usage:
- DATA (ranges, records, records, record structs, primary constructors, init-only setters and nullable references)
- BEHAVIOUR (“just” pattern matching)
- SYNTAX (extension methods, lambda expressions, lambda types, expression-bodied methods)
- Explaining the WHY
The last step can only be done by performing the former steps.
LINQ (made possible by generics, expression methods, lambda expressions and expression trees) and immutable collections (from .NET core 1, made possible by the same features as LINQ) were the first big examples of the WHY as it allowed mixing OOP and functional paradigms.
People more closely familiar to F# would probably have guessed by .NET core 1 (and maybe even by C# 3: LINQ prerequisites) that C# was heading steadily into supporting functional programming very well.
That is really the WHY of all the other big C# language enhancements.
The WHY of going functional is separating data and behaviour.
And that is needed because of how we develop software today: with the ever spreading of dependencies on external services, stacks or other data storage (or APIs not even having their own storage) we have far less influence on underlying data models and interfaces. More often than not we are mapping or rewriting data from one set of domain models to another set. Pattern matching based on functional programming is way easier to write and comprehend than procedural coding styles.
Delphi 12, stuck between the language level of C# 3 and C# 4 and a few features of later C# versions is indeed light-years behind.
–jeroen