Question

I am developing a generic wrapper around TryParse, as follows:

    public delegate bool ParseDelegate<T>(string s, out T result);

    public static T? ParseOrNull<T>(this string value, ParseDelegate<T> parse) where T : struct
    {
        T result;
        var parsed = parse(value, out result);
        return parsed ? result : (T?)null;
    }

    [Test]
    public void ParsesValidInt()
    {
        Assert.AreEqual(1234, "1234".ParseOrNull<int>(int.TryParse));
    }

    [Test]
    public void ParsesValidDecimal()
    {
        Assert.AreEqual(12.34M, "12.34".ParseOrNull<decimal>(decimal.TryParse));
    }

This is kinda repetitive. Is there a way to avoid mentioning int.TryParse at all, so that my calls look as follows:

"1234".ParseOrNull<int>()

Answer 1

Is there a way to avoid mentioning int.TryParse at all, so that my calls look as follows:

Not directly, as TryParse isn’t part of a shared interface. If there were a shared interface to these value types, this would be possible via a constraint.

---

Personally, I would not suggest using extension methods for this. I would rather write this as something more like:

public static class Parse
{
    public delegate bool ParseDelegate<T>(string s, out T result);
    public static T? FromString<T>(string value, ParseDelegate<T> parse) where T : struct
    {
        T result;
        var parsed = parse(value, out result);
        return parsed ? result : (T?)null;
    }
    public static int? ToNullableInt32(string value)
    {
        return FromString<int>(value, int.TryParse);
    }
    public static double? ToNullableDouble(string value)
    {
        return FromString<double>(value, double.TryParse);
    }
}

This adds a bit of overhead up front, but allows you to write these very cleanly, ie:

    int? first = Parse.FromString<int>("1234", int.TryParse);
    int? second = Parse.ToNullableInt32("1234");
    double? third = Parse.ToNullableDouble("1234");

I see little value in putting an extension method, especially on something like string (which is used everywhere), as it “pollutes” the compilation of string itself. You’ll see this everywhere you use strings – basically, any time you use this namespace, you’ll end up having these parse methods in your intellisense, etc. In addition, this seems more like a “utility” than something that should appear as built-in functionality of string itself, which is why I personally prefer a separate class for it.