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…
In my previous post, I outlined a list of requirements for non-nullable (and explicitly-nullable) reference types in C#. In this post we’ll dive into some further design decisions. Subsequent posts will look at the impact on generic types, plus backward-compatibility and some corner cases.
Expanding the type system
We add two new main concepts to the type system:
- non-null reference types T, denoted as ‘
- explicitly-nullable reference types, ‘