¿Hay una razón técnica por la que C# no emite la "cola"?"CIL instruction? [duplicar]

Posible Duplicado:
¿Por qué. net/C# no elimina la recursión de cola?

Tome el siguiente código C#:

using System;

namespace TailTest
{
    class MainClass
    {
        public static void Main (string[] args)
        {
            Counter(0);
        }

        static void Counter(int i)
        {
            Console.WriteLine(i);
            if (i < int.MaxValue) Counter(++i);
        }
    }
}

El compilador de C # (mío de todos modos) compilará el método Contador en el siguiente CIL:

.method private static hidebysig default void Counter (int32 i) cil managed 
{
.maxstack 8
IL_0000:  ldarg.0 
IL_0001:  call void class [mscorlib]System.Console::WriteLine(int32)
IL_0006:  ldarg.0 
IL_0007:  ldc.i4 2147483647
IL_000c:  bge IL_0019
IL_0011:  ldarg.0 
IL_0012:  ldc.i4.1 
IL_0013:  add 
IL_0014:  call void class TailTest.MainClass::Counter(int32)
IL_0019:  ret 
}

El problema con el código anterior es que causará un desbordamiento de pila (aproximadamente i=262000 en mi hardware). Para evitar este problema, algunos idiomas hacen lo que se llama eliminación de tail-call o tail-call optimización (TCO). Esencialmente, convierten la llamada recursiva en un bucle.

Entiendo que la implementación de 64 bits del JIT.NET 4 ahora realiza TCO y evita el desbordamiento en el código como el CIL anterior. Sin embargo, el JIT de 32 bits no lo hace. La mononucleosis tampoco lo parece. Es interesante que el JIT (que está bajo presión de tiempo y recursos) hace TCO mientras que el compilador de C# no lo hace. Mi pregunta es ¿por qué el compilador de C# no es más consciente del TCO?

Hay un CIL instrucción que le dice al JIT que realice el TCO. Por ejemplo, el compilador de C# podría generar el siguiente CIL:

.method private static hidebysig default void Counter (int32 i) cil managed 
{
.maxstack 8
IL_0000:  ldarg.0 
IL_0001:  call void class [mscorlib]System.Console::WriteLine(int32)
IL_0006:  ldarg.0 
IL_0007:  ldc.i4 2147483647
IL_000c:  bge IL_001c
IL_0011:  ldarg.0 
IL_0012:  ldc.i4.1 
IL_0013:  add 
IL_0014:  tail.
IL_0017:  call void class TailTest.MainClass::Counter(int32)
IL_001c:  ret 
}

A diferencia del original, este código no se desbordará y se ejecutará hasta completarse incluso en el JIT de 32 bits (tanto.NET como Mono). La magia está en la instrucción CIL tail.. Compiladores como F # generarán CIL que incluye esta instrucción automáticamente.

Así que mi pregunta es, ¿hay alguna razón técnica por la que el compilador de C# no hace esto?

Consigo que históricamente tal vez no ha valido la pena. Código como Counter() no ha sido común en C# idiomático y/o en.NET framework. Puede ver fácilmente el TCO para C # como una optimización innecesaria o prematura.

Con la introducción de LINQ y otras cosas, parece que los desarrolladores de C# y C# se están moviendo en direcciones más funcionales. Por lo tanto, sería bueno si el uso de recursión no fuera una cosa tan insegura de hacer. Pero mi pregunta es realmente más técnica.

Am falta algo que hace que TCO como esta sea una mala idea (o una arriesgada) para C#. ¿O hay algo que hace que sea particularmente difícil de hacer bien? Eso es realmente lo que espero entender. ¿Alguna idea?

EDIT: Gracias por la gran información. Solo quería dejar claro que no estoy criticando la falta o incluso exigiendo esta característica. No estoy muy interesado en lo racional en torno a la priorización. Mi curiosidad es ¿qué obstáculos podría no percibir o entender que hacen de esto una cosa difícil, peligrosa o indeseable de hacer.

Tal vez un contexto diferente ayude a enfocar la conversación...

Digamos que iba a implementar mi propio lenguaje similar a C#en el CLR. ¿Por qué no incluiría (aparte del costo de oportunidad) la emisión automática y transparente de la 'cola.¿instrucción donde sea apropiado? ¿Qué desafíos encontraría o qué limitaciones introduciría al apoyar esta característica en un lenguaje muy parecido C#.

Gracias de nuevo (y de antemano) por las respuestas.