v4 change of collections being null by default could have benefited from nullable annotations

[danielmarbach]

I would like to provide some feedback regarding the change of having the collections by default be null. While this is a good change from an allocation perspective, it is challenging to discover all the places where the code paths need to be changed. If the team had opted into changing the generator to produce models with nullable annotations on the collection types all customers upgrading and already having nullable context enabled or temporarily enable nullable context on a file by file basis could benefit from the compiler guiding through the change.

// cc @normj

[normj]

@danielmarbach Changing the generator to use the nullable reference types to help with collections was something we debated many times. I still debate in my head after GAing the SDK. The challenges we had with nullable reference types is they had questionable support for .NET Framework and the bigger issue is we would really have to mark every property of every type used for requests and responses as nullable. Since every property has a setter. That would have caused a lot of fiction changing the datatype of every property.

We added some Roslyn analyzer's to help with the detection but I would like to see if we can add more to help with compile time checks.