Question

Inspired by Phil Haack’s attempt on null or empty coalescing, I’m trying to write a couple of extension methods for the string object, as well as on the IEnumerable<T> interface, to simplify null or emtpy ckecking. However, I’m running into problems: when I’m attempting to call the string version of AsNullIsEmpty, the compiler treats my string as an IEnumerable<char>, and of course gives the wrong return type.

Is there any way to put an “anti-constraint” on the definition of the IEnumerable version, so that I can tell the compiler to use that one whenever the type of T is not string? Something like

public static IEnumerable<T> AsNullIfEmpty(this IEnumerable<T> items)
    where T !: string

I know that I could just change the name of one of them, but I want to have the same name for consistency.

Update: It turns out my problem with the extension methods was solved another way, by fixing a simple and stupid error (I was using str.IsNullOrEmpty(), the extension method on IEnumerable<T>, instead of string.IsNullOrEmpty(str)…) but since the question of anti-constraints on generics is still an interesting one, I won’t delete it.

Answer 1

The only way to do this would be to create an overload of this extension that accepts a string as its this parameter.

public static string AsNullIfEmpty(this string value)

Doing this will cause the specifically-typed version to be considered a better overload match than the generic version.

As to your specific question (“Can I specify an ‘anti-constraint’ on a generic type parameter?”), the answer is no. You could get very close, though, with the Obsolete attribute.

[Obsolete("AsNullIfEmpty is not supported for strings.", true)]
public static string AsNullIfEmpty(this string value)

This would cause the compiler to report an error for this overload.