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:
- not possible in case
input
is of non-nullable type - in case
input
would be itselfnull
, behavior would be altered
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)
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, soinput
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
isnull
, then the second snippet has no way of differentiating betweenattribute
beingnull
, when it should befalse
, and whereDescription
isnull
, where it should betrue
.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.