Is this C# 'hack' a bad idea?
First of all, I would question the need for such interface. It makes sense for a type to hold a value, but I think it doesn't make much sense for a type to decide to what types to convert that value, or how.

Second, if you really do need this, then I would prefer each target type to have a separate method, like ConvertToInt() (or ConvertToInt32() if you follow the naming guidelines).

You don't necessarily need an interface for this, but even if you do, you're exchanging a small inconvenience in implementation (having to write few very simple interfaces with some repetition) for a big inconvenience in usage (having to write that Specialisation&lt;int&gt;.Instance every time and making the code less readable). So, I think using this approach is worth it even with interfaces.

Third, if you really do need this and you want to take advantage of generics, you could use explicit interface implementation and casting to decide to what type to convert. Something like:

public interface IConvertible&lt;T&gt;
{
    T Convert();
}

public sealed class ConvertMe : IConvertible&lt;int&gt;, IConvertible&lt;float&gt;
{
    public double Value;
    int IConvertible&lt;int&gt;.Convert() { return (int)Value; }
    float IConvertible&lt;float&gt;.Convert() { return (float)Value; }
}

public static class Program
{
    public static void Main()
    {
       ConvertMe c = new ConvertMe();
       c.Value = 12.3456789;
       Console.WriteLine(((IConvertible&lt;int&gt;)c).Convert());
       Console.WriteLine(((IConvertible&lt;float&gt;)c).Convert());
    }
}


This results in code that is shorter and more readable (I think) than your version.

One issue with it is that if you don't make ConvertMe sealed, trying to convert to an unsupported type becomes a runtime exception, instead of a compile-time error.