Why string has been changed to non-nullable in C# 8?

[Kathiresan Moorthy]

Till C# 7, string can accept null values, why the concept of non-nullable is introduced in C# 8. This sounds weird. It doesn't makes sense to use "string?". Some one please clarify.

If the idea is to avoid just null references. As a C# developer, I've noticed most of the C# developers handle string checking for null always. So this feature doesn't seem to be really helpful, rather introduced a confusion. I've seen Null reference exceptions mostly when objects are referred without checking if it's null.

IMO, I may be missing the greatness of this new feature, but this really introduce complexity in understanding what string type is. string basically should accept a "null". Non-nullable string doesn't makes sense.

 

[JohnH]

I've just barely read about this before, this article explains it I guess: Design with nullable reference types | Microsoft Docs
Here are some quotes from it:

C# 8 introduces nullable reference types, which complement reference types the same way nullable value types complement value types.

You can use these new types to more clearly express your design intent: some variables must always have a value, others may be missing a value.

You must opt into the nullable reference types feature, even in C# 8 projects. That's because once the feature is turned on, existing reference variable declarations become non-nullable reference types

As I understand, if you enable this feature all reference types (including string class) becomes non-nullable, and you must express any reference type you want to allow nulls with the ? type marker.

Also some more to read here: Nullable reference types | Microsoft Docs

 

[jmcilhinney]

Non-nullable string doesn't makes sense.

Of course it does. You're confusing the type with the usage of the type. If you're talking about a reference to a string then obviously that reference can technically contain null but if you're talking about the usage of the type then of course there are times where a particular string field or property not having a value is nonsensical. For instance, let's say that you have a Country class. How would it make sense for the Name property of a Country object to be null? Sure, it is technically possible but, in usage, it makes no sense. This feature is allowing C# developers to determine whether a particular reference type variable or property is nullable based on usage, i.e. the rules of their app rather than the rules of the language. It means that null checks now only have to be performed to determine flow of execution rather than to avoid exceptions, thus making code simpler. Of course, you'd still have to test for empty strings in many cases.

 

[JohnH]

I just wonder for the string class in particular, would a non-nullable string allow assignment of string.Empty / "" ? Since that semantically equals null, even though by reference is it not null?

 

[jmcilhinney]

I just wonder for the string class in particular, would a non-nullable string allow assignment of string.Empty / "" ? Since that semantically equals null, even though by reference is it not null?

I won't know for sure until I try but I would think that it would, since the compiler will be checking for null references only.

 

[Sagar-Jaybhay]

C# 8 & No More NullReferenceExceptions – What about legacy code?

A .NET guideline specifies that an application should never throw a NullReferenceException. However, many applications and libraries do. The NullReferenceException is the most common exception happ…

csharp.christiannagel.com

string s1 = "sagar jaybhay"; // null is not allowed
string? s2 = null; // a nullable string

While the syntax with value types and reference types now looks similar, the functionality behind the scenes is very different.

• With value types, the C# compiler makes use of the type Nullable. This type is a value type and adds a Boolean field to define if the value type is null or not null.
• With reference types, the C# compiler adds the Nullable attribute. Version 8 of the compiler knows about this attribute and behaves accordingly. C# 7 and older versions of C# don’t know about this attribute, and just ignore it.