Por que as sobrecargas de String.Format existem?

Eu estava usando o Reflector para examinar a implementação de String.Format e sempre tive a impressão de que as sobrecargas de String.Format que usavam 1, 2 e 3 argumentos eram versões otimizadas do método que utiliza uma matriz de objetos. No entanto, o que descobri foi que, internamente, eles criam uma matriz de objetos e depois chamam um método que utiliza uma matriz de objetos.

1 arg

public static string Format(string format, object arg0)
{
    if (format == null)
    {
        throw new ArgumentNullException("format");
    }
    return Format(null, format, new object[] { arg0 });
}

2 args

public static string Format(string format, object arg0, object arg1)
{
    if (format == null)
    {
        throw new ArgumentNullException("format");
    }
    return Format(null, format, new object[] { arg0, arg1 });
}

3 args

public static string Format(string format, object arg0, object arg1, object arg2)
{
    if (format == null)
    {
        throw new ArgumentNullException("format");
    }
    return Format(null, format, new object[] { arg0, arg1, arg2 });
}

Matriz de objetos

public static string Format(string format, params object[] args)
{
    if ((format == null) || (args == null))
    {
        throw new ArgumentNullException((format == null) ? "format" : "args");
    }
    return Format(null, format, args);
}

Internamente, todos acabam usando o mesmo código e, portanto, as versões 1, 2 e 3 do argumento não são mais rápidas que a versão da matriz de objetos.

Então, minha pergunta é -por que eles existem?

Quando você usa a versão da matriz de objetos com uma lista de valores separados por vírgula, o compilador converte automaticamente os argumentos em uma matriz de objetos por causa da palavra-chave params / ParamArray, que é essencialmente o que as versões 1, 2 e 3 fazem, para que pareçam redundantes. Por que os designers da BCL adicionaram essas sobrecargas?

questionAnswers(2)

yourAnswerToTheQuestion