Typescript: for..of con iteradores

Esto ya está permitido si su objetivo es ES6:

interface MyMap<T> {
    values(): Iterable<T>;
}
var myMap: MyMap<string>;

for (let value of myMap.values()) {
    var s: string = value;
}

Las razones por las que esto no está permitido en ES5 / ES3 son:

• Uno de los axiomas de TypeScript es no hacer una emisión dirigida por tipos. es decir, que el código emitido no depende de lo que piensa el sistema de tipos sobre su código, sino más bien como una transformación sintáctica de su fuente de entrada.
• Hacer la emulación del iterador completo significará que tendremos que depender de un pollyfill para Symbol, nuevamente otra cualidad que nos gusta mantener
• La lógica de iteración completa generada no es barata, debe llamar a next () y verificar hecho, si falla, regrese si no usa el valor. esto es un envío adicional, dos búsquedas de propiedades y una asignación de objeto en cada iteración de un bucle. Hemos tratado de que el código emitido sea simple y se pueda relacionar con la fuente, especialmente en las características de rendimiento.
• Finalmente, para hacer todo eso en objetos iterables personalizados, todavía tenemos que hacerlo en Arrays, ya que los Arrays no tienen este soporte en ES5 / ES3, y no queremos hacer una emisión dirigida por tipo, necesitamos convertir un arreglo a un iterable, que es drásticamente más lento de lo normal para el bucle. y el problema principal es que, al observar un bucle en una matriz, no queda claro que incurriría en este costo.

Como resultado de estos factores, en ES3 / ES5 solo se permiten matrices en for..of bucles (como los objetos iterables más comunes disponibles en el lenguaje JS en la actualidad); en cuanto a la orientación a ES6 (es decir, con soporte de motor en tiempo de ejecución para iterables y arreglos iterables) se permiten iterables personalizados además de Array, string, map and set, .. etc.

Entendido...
@mhegazy ¡¡¡ Muchas gracias por su respuesta detallada !!!

Encuentro esto realmente decepcionante. Puedo usar for-of con cualquier ES5 iterable y objetivo con Traceur y Babel hoy. Estoy interesado en proponer que nuestro equipo cambie de Traceur a TypeScript, pero esta limitación en TypeScript evitará que eso suceda. Cuando TypeScript dice que pretende ser un superconjunto de ES6, creo que debe incluir la capacidad de apuntar a los navegadores ES5 para todas las funciones de ES6 que admite.

Supongo que podría usar TypeScript para apuntar a ES6 y luego ejecutar esa salida a través de Traceur o Babel. Aunque realmente no quiero tener que hacer eso.

Como actualización para este problema, el protocolo iterador ahora es compatible con el destino ES3 / ES5 usando --downlevelIteration . Consulte el n.º 12346 para obtener más información.

Parece que se supone que esto está arreglado para TS 2.3, pero estoy ejecutando TS 2.3.3 y

      for (let [ i, observationPoint ] of observationPointsList.entries())
        observationPoints[ observationPoint.spot || (i + 1) ] = observationPoint;

donde observationPointsList es un ObservationPointModel[] , produce:

[11:30:56]  typescript: src/models/observation-set.ts, line: 44 
            Type 'IterableIterator<[number, ObservationPointModel]>' is not an array type or a string type. 

¿Me estoy perdiendo de algo?

@lhunath debe especificar la opción --downlevelIteration .

Ah, en verdad. No puedo ver en esta documentación o en el n. ° 12346: ¿por qué está oculto detrás de una opción en lugar del comportamiento estándar? ¿Será esto siempre opcional?

@lhunath está en la información de lanzamiento oficial de 2.3 . Es opcional porque tiene un impacto muy significativo en el tamaño del código generado, y potencialmente en el rendimiento, para todos los usos de iterables (incluidas las matrices). Creo que la compensación vale la pena por la mayor expresividad, pero hacer que el código existente sea más lento y más complejo parece una justificación razonable para que haya una bandera.