It’s not uncommon to write code similar to the following:
var result = source.Where(x => x != null).Select(x => x.Something);
While it doesn’t save a lot of typing, it’s convenient to define the following
new extension method for IEnumerable<T>:
public static IEnumerable<T> WhereNotNull<T>(this IEnumerable<T> source)
where T : class
{
return source.Where(x => x != null);
}
If T were a nullable type, the example code would need to have a seemingly-unnecessary Nullable<T>.Value property access:
var result = source.Where(x => x != null).Select(x => x.Value.Something);
Additionally, tools like ReSharper will give a spurious “Possible
‘System.InvalidOperationException’” warning on the .Value access, because they
can’t (currently) infer that all items will have a value.
If we create an overload of WhereNotNull that transforms IEnumerable<T?> to
IEnumerable<T>, we solve both these problems:
public static IEnumerable<T> WhereNotNull<T>(this IEnumerable<T?> source)
where T : struct
{
foreach (T? t in source)
{
if (t.HasValue)
yield return t.Value;
}
}
Now, the example code looks the same, whether source is a sequence of
reference types or nullable value types:
var result = source.WhereNotNull().Select(x => x.Something);
(Full source code for this post is available in EnumerableUtility.cs.)
Posted by Bradley Grainger on April 21, 2010