I know that it's a bit too late to jump into the train, as it was merged, but I find this change a bit questionable and am concerned about usability of it. For example here now T is nullable, but that's not the case at all. It depends solely on the method we invoke whether the value is null or not. I understand that we don't have a chance to infer that somehow - but yet now people will be forced to use null-forgiving operator. That isn't convenient at all. It's like .ToString()! you have to write all the time - it's annoying and it frankly sucks 😟

The primary purpose of this library is to enable unit testing. I would find it quite surprising that people would have nullability enabled in the unit tests, as.. well, it's unit tests, not the production code and you want to have flexibility there. I could totally see that some are enabling, but yet I wouldn't imagine it being the default.

My primary argument is that we cannot promise nullability or describe anything meaningful - shall we just not enable it for classes like Arg? Like if you don't know the answer to the question - you just say "I don't know" instead of pretending you know something. After this change the compilation could break for the existing test projects (if they have the nullability enabled) and people will have to go and manually suppress it everywhere - isn't it annoying?

@Romfos @dtchepak What are you thoughts on this?

@zvirja Thanks for the thoughts. I haven't used C# since nullability changes (mainly Kotlin at the moment), so not across this. This hasn't made it to release so it's fine to revert.