Add IsNullOrEmpty extension method to System.Linq.Enumerable and Queryable - by Diego B Vega [MSFT]

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 287482 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 7/14/2007 2:32:23 PM
Access Restriction Public


This suggestion consists of enabling IsNullOrEmpty as an extension method applicable to all kinds of enumerable types, and also as a boolean operator for Linq query expressions.
Sign in to post a comment.
Posted by Microsoft on 4/24/2008 at 4:40 PM
Thanks again for your suggestion. After having done feature planning for the next release of C# I regret to say that this feature is not being added. We have to do some harsh prioritization, both because of our implementation and testing resources, but also because we need to keep the number of new langauge features at a manageable level - depending on how you count, we are adding only four language features to C# this time around. Unfortunately many great suggestions just can't make it in because of that.

I apologize that this is a "canned" follow-up answer, sent out as a result of our feature planning for the next release. In most cases I or someone else already replied individually to your suggestion - please let us know if you feel it hasn't been adequately addressed.

Thanks again for taking the time to share your ideas with us. Please keep them coming!

Mads Torgersen, C# Language PM.
Posted by Microsoft on 10/16/2007 at 10:20 AM
I see. I suppose we could consider having Enumerable.IsNullOrEmpty<T>(IEnumerable<T> source).

It's implementation would be simple: return (source == null) || !source.Any();

We'll consider this convenience method for LINQ 2.0.

As for the "extension method on null" thing we very deliberately kept it as a guideline only. Our goal is not to use all sorts of tricks to make extension methods work exactly like instance methods. Rather we tried to make the mechanism whereby they are resolved be as simple as possible. Automatically injecting null checks would not fit that bill, and would be unnecessarily restrictive.

Thanks again for your comments!

Posted by Diego B Vega [MSFT] on 7/18/2007 at 10:51 PM
Hello Mads,

Thanks for your answer! I have several observations, so please stay with me:

My motivation to ask for the inclusion of IsNullOrEmpty in Enumerable and Queryable has more to do with the wide applicability of such a method than with the wish not to prefix the call with a class name.
In that sense,


would be as acceptable as (or more acceptable than):


My understanding is that the System.Linq will be imported by default on all kind of C# and VB projects, and the Enumerable class is already fully inhabited by methods that apply to IEnumerable types (most, but not all of them are extension methods), hence that was my thought flow when I asked for IsNullOrEmpty to be included there.

Regarding static imports, am not against them, but I am not sure I really need them. I think they also have their own share of issues and horror stories.

About your guidelines on extension methods, a few thoughts:

I always understood that it could be counterintuitive to allow instance method syntax on null instance variables. However, I thought that per the definition of extension methods, such a thing could exist if the semantics justified it.

Actually, I am still wondering: If the C# team idea is “absolutely no null this parameters on extension methods”, then why didn’t you define them to always do the check on runtime.

Right now, I think roughly 2 and a half KB of LINQ to Objects code is dedicated to do this:

    L_0000: ldarg.0
    L_0001: brtrue.s L_000e
    L_0003: ldstr "source"
    L_0008: call class [mscorlib]System.Exception System.Linq.Error::ArgumentNull(string)
    L_000d: throw

Well, my guess is that it would be more costly to inject the check in client code each time an extension method was called.

By the way, LINQ to Objects is going to be included in the Silverlight CLR, right? I think I can see some low hanging fruit to reduce System.Linq footprint without performance penalties. I guess I will post another suggestion...

Once more, thank you.

Posted by Microsoft on 7/18/2007 at 11:54 AM
Thanks for your suggestion.

We actually use IsNull as a kind of horror example of how not to use extension methods! Extension methods allow instance method call syntax, and the intuition therefore is - and should be - that the method is invoke _on_ the object. If it still works when there _is_ no object, that is confusing, and if the method is even _meant_ to be invoked on null, it is directly counterintuitive.

The IsNullOrEmpty method should really be a static method, not an extension method.

I suspect your real reason for having it as an extension method is not to get the instance method call syntax, but to save having to put a class name in front of your static method call. Is that the case? We have a proposal for allowing static members to be imported directly into scope (like Java's static import). Would that address your needs?

THanks again,

Mads Torgersen, C# Language PM