C# Non-Nullable Types: Backwards Compatibility
In previous episodes I proposed a set of requirements for non-nullable reference types in C#/.NET, and a proposed design, including their interaction with generic types (polymorphic types).
There is also something to be said about backwards- and forwards- compatibility:
- How can legacy code — using implicitly-nullable reference types — be migrated to using non-nullable references without causing disruption?
- How should legacy code interact with APIs which accept or return non-nullable reference types?
- What are the implications of generic code to backwards compatibility?
I’ve been developing a mobile app with Ionic 2/Angular 2/Cordova/TypeScript, and given how many moving parts there are in there, and that Ionic 2 and Angular 2 were still beta software when I started—and that I was completely new to all of the technologies when I started—it’s gone relatively well.
However, it’s not a totally smooth development experience, and there are lots of little annoyances which occasionally turn it from pleasant to hideously frustrating.
It’s Marching Season in Glasgow.
I’ve described some design requirements for implementing non-nullable and explicitly-nullable reference types in C#, and a design which meets those requirements.
However, there are two major items I’ve not yet discussed: how these null-aware types interact with .NET generic types, and how they interact with legacy code containing implicitly-null reference types.
In this episode, Generics:
In this series so far:
- Some requirements for null-aware types in C#
- A basic design
- (This article) A wee digression
- (Next time) How the design affects generic types
- (Probably) Compatibility
- (Probably) The Future
In this article we’ll digress about default values…