[WirelessGigabit]

If TeamId is a non-nullable string then the construction of that object should fail when TeamId is null, not at the consumption site.

This is exactly the issue what Rust is solving. A struct construction completes or fails. There is no weird in between state.

[piaste]

They could easily have declared TeamId as non-nullable in modern C# too.

The issue they had is:

(a) TeamId is legitimately nullable at creation, there are valid SlackEvents without a TeamId

(b) They wanted to assert "TeamId won't be null" from a certain point in the code path

(c) They didn't want to create a different data structure (TeamSlackEvent or something) to hold the definitely-has-a-TeamId events.

I strongly suspect (c) was a mistake and they were just too lazy to define a new (sub)-class or record.

[MobiusHorizons]

That’s all well and good when you write both the consumer and producer. But how do you detect consumers which depend on some data integrity aspect you need to change for whatever reason?

[masklinn]

The types or constructors ought change to match?

If TeamId goes from non-nullable to nullable, it goes from TeamId to Option<TeamId>, and consumers get a type error.