IEnumerable<T> null coalescing Extension

Question

I frequently face the problem to check whether an IEnumerable<T> is null before iterating over it through foreach or LINQ queries, then I often come into codes like this:

var myProjection = (myList ?? Enumerable.Empty<T>()).Select(x => x.Foo)...

Hence, I thought to add this extension-method to an Extensions class:

public static class MyExtensions 
{
    public static IEnumerable<T> AsEmptyIfNull<T>(this IEnumerable<T> source)
    {
        return source ?? Enumerable.Empty<T>();
    }
}

A little issue comes immediately in my mind looking at this code, i.e., given the "instance-methods aspect" of extension-methods, it should be implemented as a mere static method, otherwise something like this would be perfectly legal:

IEnumerable<int> list = null;
list.AsEmptyIfNull();

Do you see any other drawback in using it ?
Can such extension leading to some kind of bad-trend in the developer(s), if massively used?

---

Bonus question:

Can you suggest a better name to it ? :)
(English is not my first language, then I'm not so good in naming...)

Thanks in advance.

Chalybite

What is the problem? Wouldn't you want that to be legal? That would be legal with a static method also, but I thought that the whole point was to make that legal, which is true using an extension or static method. – Conover

@recursive: did you refer to the "little-issue" part or to the whole question ? If it's the former, I just think that reading the code could be a bit strange for "instance-methods accustomed" people. If the latter, well my question is exactly about the correctness to spread such an extension method (for example in a company-shared utilities assembly) because could lead to bad behaviours... – Chalybite

When using this extension, if the type is not inferred, try adding .AsEnumerable() before .AsEmptyIfNull(). Also, I prefer to call the method EmptyIfNull because As implies casting, which does not take place here. DefaultIfEmpty is not named AsDefaultIfEmpty either. – Azotize

Answer 1

Methods that return an IEnumerable<T> should return an empty one, instead of null. So you wouldn't need this.

See this question : Is it better to return null or empty collection?

Otherwise, your code seems ok.

Philosophize

Yes, that's true, but not always you can change the code to get this result (e.g. when using API). To give a real example, try to serialize an empty list with protobuf, then deserialize it: you will get null :) – Chalybite

Answer 2

It's generally a bad idea to return a null instead of an empty sequence if you can control it. This is self-explanatory if you consider that when someone is asked to produce a collection, returning null is not like saying "the collection is empty" but "there is no such collection at all".

If you own the methods returning the enumerables, then returning an empty IEnumerable (which can even be a special purpose readonly static object if it might be returned a lot) is the way to go, period.

If you are forced to use a bad-mannered library that has the habit of returning null in such cases, then this an extension method might be a solution, but again I wouldn't prefer it. It's probably better to wrap the bad-mannered methods in your own versions that do the coalescing where people won't see it. This way you get both the convenience of always having an enumerable instead of null and the correctness of not supporting the "return null" paradigm.

Aqaba

Yes, probably the best thing to do is to wrap bad-mannered libraries. Anyway, create this kind of extension doesn't seem so harmful, does it ? – Chalybite

@digEmAll: The harm is only that people who see it might think that it's OK for methods to return null instead of empty collections and write their own such methods, which would perpetuate the problem. Other than that, I don't see any harm. – Aqaba