Null-or-Empty coalescing operator for string types

[ActivistInvestor]

Proposal: Null-or-Empty Coalescing Operator ($?)

Summary

Introduce a new null-or-empty coalescing operator ($?) in C# that simplifies handling of null or empty ("") string values, similar to the existing ?? null-coalescing operator.

Motivation

Currently, developers frequently check for null or empty strings using string.IsNullOrEmpty(). This results in verbose expressions when assigning default values, such as:

string result = !string.IsNullOrEmpty(str) ? str : "default value";

Alternatively, we can use:

string result = string.IsNullOrEmpty(str) ? "default value" : str;

However, these approaches can be cumbersome, reduce readability, and lead to inconsistent handling of empty strings. The existing ?? operator only handles null values, which can cause subtle bugs when empty strings should also be treated as missing values.

Proposed Syntax

Introduce a new operator $?, which functions similarly to ??, but treats both null and empty ("") strings as equivalent to null.

Example Usage

string result = str $? "default value";

Equivalent Expansion

The above expression would be functionally equivalent to:

string result = string.IsNullOrEmpty(str) ? "default value" : str;

Behavior Table

str Value	Expression (str $? "default value")	Result
null	string.IsNullOrEmpty(null) ? "default value" : null	"default value"
"" (empty)	string.IsNullOrEmpty("") ? "default value" : ""	"default value"
"hello"	string.IsNullOrEmpty("hello") ? "default value" : "hello"	"hello"

Advantages

• Improves Readability: Eliminates verbose string.IsNullOrEmpty() checks.
• More Consistent Handling: Ensures empty strings are treated the same as null when defaulting values.
• Aligns with Existing ?? Operator: Provides an intuitive extension of existing null-coalescing behavior.
• Reduces Common Mistakes: Prevents unexpected issues where ?? fails to handle empty strings.

Potential Challenges

• Operator Parsing Conflicts: $? must be validated to ensure it does not conflict with existing C# syntax.
• Type Constraints: The operator should be restricted to string types to prevent unintended behavior in non-string scenarios.

Alternative Approaches Considered

1. Extending ?? to Treat Empty Strings as null
   • Could introduce breaking changes for existing code.
   • Would change fundamental behavior of ?? beyond its current null-handling scope.
2. Introducing a Built-in Helper Method
   • Example: string.Coalesce(str, "default value").
   • Still more verbose than a dedicated operator.

Conclusion

The proposed $? operator provides a simple, readable, and intuitive way to handle null or empty strings in C#. By aligning with the existing ?? operator's behavior while extending its functionality to handle empty strings, it improves developer experience and code maintainability.

---

(This proposal was drafted using ChatGPT)

[HaloFour]

See: #183

[siegfriedpammer]

This proposal was drafted using ChatGPT

That's why it is overly verbose and contains lots of filler words. 🤣

[ActivistInvestor]

Probably true, but I didn't have to do very much typing. ;)

I think this resource would see much more feedback if contributors didn't have to write a book.

[siegfriedpammer]

I think this resource would see much more feedback if contributors didn't have to write a book.

I think this is a misconception. A proposal does not get better if it's longer.

If you read the C# language specification, you will see that despite its length, it's actually terse technical English that only lists necessary facts and relationships between all the language elements, but it goes into details and provides examples. And its very long just because the language is a complex thing.

I think, you can find good examples of language proposals if you look at some of the proposals in this repository. (https://github.com/dotnet/csharplang/tree/main/proposals)

In my opinion, a good proposal...

• ... lays out the motivation for the feature
• ... contains examples that show why a language feature is necessary and compares these examples with existing solutions
• ... explores if there are any conflicts with existing language features or breaking changes
• ... contains a detailed exploration of how the compiler should transform this into MSIL (aka .NET byte-code) or equivalent C# (and the pros and cons of different implementation strategies)
• ... explores if there are any runtime changes necessary (and potential pros and cons)
• ...

I am not saying this list is complete, nor that your proposal is missing all of these.

Just one example:

Operator Parsing Conflicts: $? must be validated to ensure it does not conflict with existing C# syntax.

This is an empty statement. It does not contain any new information and is typical for LLMs. Instead of stating this, a proposal should explore the existing C# syntax and actually list any conflicts.

And I would just strip the "summary" and "conclusion" sections for such a mini language feature. For larger more complex features a "summary" can be added at a later point. This text structure is very reminiscent of academic texts and doesn't really fit into technical writing, IMHO.

Note, I am not any authority, I am just reading these proposals and specifications a lot, because I spend my work and hobby time with implementing developer tools for the .NET ecosystem and the C# language.

@CyrusNajmabadi are there any resources that new contributors can read to learn how to write a good proposal? I couldn't find anything in the README.