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
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).