C# 9 to 14: Features for Better, Safer Code

Microsoft consistently releases new versions of .NET every November, a schedule that developers should anticipate and integrate into their workflow. Upgrading promptly is crucial as each new version brings significant performance enhancements and compiler improvements. While the 'Long-Term Support' (LTS) label is often associated with stability, it primarily refers to the duration of Microsoft's support, not an indication of the version's inherent stability or readiness for adoption.

Filip Ekberg emphasized the regularity of these releases, stating, "Every November, Microsoft releases a new version of .NET." This predictable schedule allows developers to plan their upgrade path and take advantage of the latest advancements.

Historically, the release cycles of C# and .NET were not always synchronized, but Microsoft has now bundled them together into a unified release schedule. This alignment ensures that a new version of C# and its compiler are released concurrently with every .NET update. The synchronized releases enable the C# language to quickly leverage new runtime capabilities and features, fostering a more integrated and efficient development ecosystem.

According to Filip Ekberg, "With every version of NET they also release a new version of C and the compiler but they're sort of bundled together in the same release." This bundling simplifies the update process for developers and ensures that language features can directly benefit from runtime improvements.

C# 6 introduced nullable reference types, a feature that, by default, treats all reference types as non-null, significantly enhancing null safety. This mechanism empowers the compiler to identify and flag potential null reference exceptions during the development phase, before code is even executed. Developers retain the flexibility to explicitly mark fields as optional using the '?' operator, signaling to the compiler that a null value is permissible in specific contexts.

Filip Ekberg explained, "Now, when I turn on the feature called nullable reference types, which is the default as of 6, the compiler will treat everything that's a reference type as something that has to be set to an instance." This change fundamentally shifts the paradigm of null handling, moving from runtime errors to compile-time warnings.

C# 11 introduced the 'required' keyword, a crucial feature designed to enforce the initialization of specific properties during object instantiation. This keyword ensures that developers explicitly set certain values when creating an object, preventing runtime errors that could arise from uninitialized properties. Complementing this, 'init' setters enable the creation of immutable properties, which are particularly beneficial in multi-threaded applications where data integrity and consistency are paramount.

Filip Ekberg noted, "With C# 11, they introduced a a feature to tell us also or tell the compiler that this is required to be specified when you print an instance of this." This mechanism provides a compile-time guarantee that essential properties are never left unset.

The C# compiler now incorporates 'null state static analysis,' a sophisticated mechanism that automatically tracks how developers perform null checks on properties, classes, and instances. This analysis allows the compiler to understand the logical flow of null checks within the codebase. By monitoring these checks, the compiler can proactively identify situations where a null reference exception might occur, effectively preventing such issues downstream in the application's execution.

Filip Ekberg highlighted that "the compiler has this thing called a null state static analysis where it keeps track of how you perform null checks on your properties and classes and instances." This proactive approach significantly enhances code reliability and reduces the likelihood of null-related bugs.

The '!' operator, often referred to as the null-forgiving operator, serves a very specific purpose: it removes the visual warning, or 'squiggle,' that the compiler displays when it suspects a potential null reference. However, it's crucial to understand that this operator does not actually fix any underlying null-related problems in the code. Essentially, it acts as a directive to the compiler, telling it to proceed as if the developer has confirmed that a value will not be null, even if that assumption might be incorrect. As Filip Ekberg plainly put it, the operator "literally just remove the squiggle."

A critical practice for enforcing high code quality is to configure the build process to 'treat warnings as errors.' This setting ensures that any compiler warning, including those related to potential null reference exceptions, will cause the build to fail. By integrating this into build and CI/CD pipelines, development teams can ensure compliance with coding standards and catch potential issues early in the development lifecycle.

Filip Ekberg strongly advocated for this approach: "That's why there's this option, treat warnings as errors. So, we turn that on." This proactive measure significantly reduces the risk of runtime errors and promotes a more robust codebase.

C# has significantly evolved its pattern matching capabilities, moving beyond traditional switch statements to more versatile and concise switch expressions. These expressions provide a functional approach to handling multiple conditions, allowing developers to define a result based on an input value in a streamlined manner. The enhanced patterns support checking types, property values, and relational logic, all with minimal code verbosity.

Filip Ekberg explained the motivation: "That's why they introduce this concept of switch expression where we can say I'd like to get a result based on an input." This feature drastically reduces boilerplate code and improves readability for complex conditional logic.

C# record types provide a concise way to define data-centric classes, automatically generating useful features behind the scenes. Key advantages include value-based equality, meaning two records are considered equal if all their property values match, rather than just their memory addresses. Records also come with a primary constructor and built-in immutability, which are crucial for creating robust and predictable data models.

Filip Ekberg defined a record as "simply just a record class which creates a class behind the scenes which gives us value based equality gives us a primary constructor um and gives us gives us immutability." This simplifies the creation of data transfer objects (DTOs) and immutable data structures, reducing boilerplate code and enhancing code safety.

The introduction of extended property patterns in C# significantly enhances null safety by incorporating automatic null checks. This means that when developers access properties on an object using these patterns, the compiler implicitly performs a null check beforehand. If the object is null, the pattern evaluation will gracefully determine that the condition is false, rather than throwing a NullReferenceException.

Filip Ekberg clarified the benefit: "That's what the extended property pattern does. So you can trust that it has performed an null check before accessing that property and just determine that this is false if that's throw an exception." This feature simplifies code by removing the need for explicit null checks, making it more robust against common runtime errors.

A rare occurrence in C# development history was the withdrawal of parameter null checking, a feature that had already been merged into the compiler. This unprecedented decision meant that the development team had to revert internal codebases that had already adopted and integrated the feature, causing significant rework. The experience served as a cautionary tale for developers.

The speaker, Filip Ekberg, noted, "This was probably the only feature I've ever heard about being withdrawn from the compiler when it was already merged." He further advised against using preview compiler versions in production environments, underscoring the potential risks associated with unstable features.

This incident highlights the importance of stable releases and the potential overhead of early adoption of experimental features.

In C# 14, 'spans' have been elevated to a more prominent status, becoming closer to first-class citizens within the language. This update introduces a greater number of implicit conversions, specifically designed to help developers build even more performant applications. Notably, the compiler now allows implicit conversion from string literals directly to read-only character spans, streamlining operations that require efficient memory handling.

Filip Ekberg stated, "With C# 14, spans are more like a first class citizen or and there's a lot of more implicit conversions to help us build even more performance applications." These changes empower developers to write more optimized code, especially for scenarios involving large data buffers or interop with unmanaged memory.

C# 12 extended the concept of primary constructors, previously exclusive to records, to regular classes. While both records and classes can now utilize primary constructors, there's a fundamental difference in their implementation and purpose. Record types are primarily designed for carrying data that is often publicly exposed, such as a `TestResult` with a `public NumberOfAttempts` property, implying that primary constructor parameters automatically become public properties.

In contrast, primary constructors on classes do not automatically expose their parameters as public properties. Instead, they function more like a concise way to inject dependencies or initialize internal state without the boilerplate of a traditional constructor. Filip Ekberg emphasized this distinction, noting that "There's a fundamental difference between a record type which is a way for you to carry data that's sort of publicly exposed as well. So you have for example a test result that has public number of attempts." This design choice allows classes to maintain their encapsulation while still benefiting from the brevity of primary constructors.

C# 14, released in November of last year, continues Microsoft's strategy of incremental language evolution, focusing primarily on refining and polishing existing features rather than introducing major overhauls. This approach aims to make the language slightly better with each iteration, enhancing developer experience and code quality. Key updates in C# 14 include elevating the 'field' keyword to a first-class citizen and broadening support for 'spans,' further optimizing performance-critical scenarios.

Filip Ekberg summarized this philosophy, stating, "They don't introduce a lot of groundbreaking stuff. It's basically polishing the things that we already have, making it slightly better. And in C# 14, it's not different." This commitment to steady improvement ensures that C# remains robust and efficient without disrupting established workflows with radical changes.

The speaker expressed reservations about the null conditional assignment feature, highlighting potential issues with code readability and debuggability. While concise, the '?' operator can sometimes make it difficult to quickly ascertain whether a null check is being performed, especially in complex expressions.

Filip Ekberg articulated his concern: "I'm a little bit torn here what I think about this because I try my best to write code that's easy to scan quickly and understand. If I see a question mark all of a sudden like it's sometimes difficult to know that this performs a null check... just be cautious with the features you add." He warned that in high-throughput or multi-threaded environments, such constructs could complicate debugging. He advised developers to exercise caution and not adopt every new language feature simply because it exists, prioritizing clarity and maintainability.

Union types, a highly anticipated feature among C# developers, have recently been merged into the compiler and are expected to make their debut in C# 15. While the current timeline suggests an arrival in C# 15, there is a possibility that the feature might still be marked as experimental or even delayed until C# 16, reflecting the iterative nature of language development.

Filip Ekberg shared this promising update: "Whenever I talk about C#, someone comes up afterwards and be like, 'Hey, when is unit types coming to C#?' Well, it was actually merged uh a couple of months ago. So, it should be coming in C# 15." Beyond union types, future language goals for C# include significant improvements in async/await runtime performance and further reductions in compiler overhead, aiming for a more efficient and responsive development experience.