use different function signature for value types and reference types

Question

I'd like to do a function like below. K and L are generic type parameters. (it's a customization of MultiKeyDictionary by Aron Weiler in case you wonder)

protected void Dissociate(K primaryKey, L subKey)
{
    primaryToSubkeyMapping.Remove(primaryKey??subDictionary[subKey]);
    subDictionary.Remove(subKey??primaryToSubkeyMapping[primaryKey]);
}

Each argument is optional but at least one needs to be present; null means the absence. The problem is, if the generic parameter is a value type, I need to wrap the function's argument with Nullable so primaryKey?? is valid and so I can pass null to specify the argument's absence. But, Nullable<K> is invalid too if K is a reference type instead!

So, can I somehow write the implementation so it's valid for both cases?

Answer 1

Botton line: this can be done but requires disproportionate amounts of overhead. So it's completely impractical.

In the end, I resolved this by adding two overloaded methods without either argument.

---

According to C# specification v.3.0, §B.2.7, type constraints can be put on single methods as well. But, these methods need to have the types the constraints are put on as their own type parameters. So, I was able to do the trick like this:

protected void Dissociate<KP,LP>(KP? primaryKey, LP? subKey)
    where KP:struct,K where LP:struct,L
{
    primaryToSubkeyMapping.Remove(primaryKey??subDictionary[subKey.Value]);
    subDictionary.Remove(subKey??primaryToSubkeyMapping[primaryKey.Value]);
}

But, now, I need to make four implementations for each combination of class and struct! And when I try to call them inside typeof(K).IsValueType-like checks, the compiler fails to get it as a hint for overload resolution and yields the corresponding error. Naming them differently only goes one step further: the compiler is not convinced that only one of them will ever be called in any concrete implementation and still fails argument type checks. Now, there are two choices:

• Call the related implementation through reflection. Getting the generic type parameter objects for GetMethod(), then making a concrete method is gonna be a PINA - even if I simplify the former step by naming the four implementations differently;

• Make four derived classes, each with a different name. This would screw up the class hierarchy.

  • To resolve the hierarchy schism (at the cost of Liskov's principle), I can make another class that would delegate to one of them. In the corresponding code, I'll face the same type check problems again and will have to resolve them in the same manner as the previous item.

  In brief, this way is completely unusable.

Answer 2

You can specify Nullable<T> as the parameter type to allow the overload. For example:

class A { }
struct B { }

class Program
{
    static void Main(string[] args)
    {
        A a = new A();
        B? b = new B();

        Method(a);
        Method(b);

        a = null;
        b = null;

        Method(a);
        Method(b);
    }

    static void Method<T>(T t) where T : class
    {
        Console.WriteLine("Reference type: " + (t != null ? "not " : "") + "null");
    }

    static void Method<T>(Nullable<T> t) where T : struct
    {
        Console.WriteLine("Nullable<T> type: " + (t != null ? "not " : "") + "null");
    }
}

In your own scenario, if the type parameters K and L can be independently a reference type or Nullable<T>, then you'll need four overloads, to take care of all the possible combinations.

You should be able to have all four overloads share a common implementation by handling the null tests in each overload and then calling a shared implementation method that doesn't care about nulls (i.e. can safely assume they've been addressed).