Lots of reasons, but mainly that I don't consider null values to be a fault of the language. Even if it were, this doesn't solve that problem.
But now we're in a situation where we still have nulls, but compiler warnings force us to decorate them and treat them the same as before. It obscures the difference between value and reference types. Plus the syntax implies Nullable<T>, which is something everyone should have learned to avoid when all it did was box value types.
The more correct solution would have been to finish the contract system that allowed you to declare a function argument as non-nullable.
Ultimately I think it was the wrong solution to something that wasn't a problem to begin with. Now we have muddied the syntax and the null situation is the same as it always has been.
Agreed that Microsoft is adding features for the sake of setting C# apart rather than making it a better language (IMO).
I strongly disagree about the treatment of null values, if there's one thing I like about C# it's that (even if it's crude, it's better than Scala's way of doing it which is Maybe or Option or something, sorry, it's been a while.) Also C# doesn't 'force' you, you have to require it before it enforces no-nulls.
> It obscures the difference between value and reference types
How, and how is that a problem?
> Plus the syntax implies Nullable<T>, which is something everyone should have learned to avoid when all it did was box value types.
Err, now I'm getting really rusty. What are you saying here?
> The more correct solution would have been to finish the contract system that allowed you to declare a function argument as non-nullable.
That's effectively what the no-null enforcement does, only it applies inside a function as well (if you make it do so anyway).
I completely disagree that it "wasn't a problem to begin with" .Hoare called it his billion-dollar mistake, and that's an underestimate. And we haven't muddied the syntax because you enable no-nulls with a pragma, and the null situation is definitely not the same as it has always been. The compiler picks them up and reports them (like I said, rather crappily but it's a damn sight better than nothing).
The question mark to denote a nullable type is inherited from the .net framework days. You'd use that to mark a value type as nullable, which is syntactic sugar for Nullable<T>. Internally, that object stores a bool for IsNull and it packs your value into an Object. When dealing with value types, this results in a copy-by-value every time you access it, which is bad in most cases.
I don't like this solution because it reuses something that I've learned is a Bad Thing. Though I'm sure the current implementation just stores a reference to the object in question.
But fundamentally, I think nulls are a good thing. Null carries information. If C/++ can handle null pointers for the last 40 years, I think C# can handle it. But then again, maybe this is a problem domain that I've just never encountered. The only problems I have with nulls is around ergonomics, but the null coalescing and safe access operators solve that for the most part. Maybe it's a bigger problem at scale, I really wouldn't know. At the scale I operate at, non-nullable reference types causes more headache than it solves problems
Why?