CODEWITHSUNDEEP
c#nulllanguage-featuresc#-6.0null-propagation-operator
Teodor Tite
Teodor Tite

Reputation: 1955

Null-propagation replacement for null check prior conditional statement

After seeing a similar question, I was wondering if the following expression ...

if (attribute != null && attribute.Description == input)

... would behave (almost) identical, to following null-propagation variant?

if (attribute?.Description == input)

So far, I could determine only following (somehow minor) differences:

Am I missing something? or are there other differences in behavior?

EDIT: in the end, the only fail-safe alternative I've found for the first snippet, would be:

if (attribute?.Description?.Equals(input) ?? false)

Upvotes: 3

Views: 1298

Answers (1)

Servy
Servy

Reputation: 203802

The code will work if input is of a non-nullable type. There is an implicit conversion of all non-nullable types to their nullable counterparts, so input will simply be lifted to a nullable to be compared to the property value.

The only difference in behavior, as you mentioned is that, if input is null, then the second snippet has no way of differentiating between attribute being null, when it should be false, and where Description is null, where it should be true.

Oh, and this is assuming that attribute is a local variable or field. If it's a property (or is actually a more complex expression) then it could have side effects or result in a different value when computed twice, as happens in the first snippet but not the second, which is a difference in behavior.

This is all of course assuming a single threaded context. In a multithreaded context, if attribute is accessible from another thread (either because it's a field that's accessible or because it's closed over in a lambda that is exposed to another thread) then the value could be different each time it's computed, so the two snippets differ for the same reason described in the previous paragraph.

Upvotes: 4

Related Questions