Für arrays ist es so implementiert, dass ein for-in einem for-to entspricht.
Reiner Zufall. Heute so, morgen anders (Rückwärtszählen geht vielleicht schneller, Speicher ist nicht mehr linear aufgebaut, wer weiß das schon).
Sich darauf zu verlassen, wie etwas implementiert ist, ist -mit Verlaub- ganz großer Käse.
Eigentlich darf man in einer For-In Schleife auch keine Änderungen an der der laufenden Enumeration zugrundeliegenden Datenstruktur vornehmen (auf Gut Deutsch: Die Liste verändern). Aber da ist Delphi wohl nicht so safe.
Zu glauben, dass sich das Verhalten einer for-in Schleife für ein Array ändert ist eher der große Käse. Die Compiler Optimierung des rückwärts zählens auf 0 bei einer for-to Schleife wird auch nur vorgenommen, wenn der Index in der Schleife nicht benötigt wird und dementsprechend die Logik des Programms nicht verändert wird. Das trifft auf eine for-in Schleife wohl auch nur dann zu, wenn man im Schleifenrumpf nix mit der Laufvariable macht. Wobei dann die Reihenfolge auch Rille wäre.
Was die Veränderung der durchlaufenden Struktur angeht ist die Implementierung in der Delphi
RTL wirklich nicht sehr dolle. In Spring4d hingegen wird dir ein Enumerator mit einer
Exception ins Gesicht springen, wenn du zwischendurch die zugrundelegende Datenmenge veränderst (analog zum Verhalten in .Net).
Ich stimme den meisten hier zu, dass es gefährlich sein kann, anhand eines abstrakten Interfaces (IEnumerable<T>) auf ein Implementierungsdetail zu schließen. Deshalb würde ich in einem solchen Fall eher vorschlagen, ein weniger abstraktes zu benutzen. In Spring4d/.Net würde sich dort z.B. IList<T> anbieten. Dieses bietet direkten Indexzugriff und man kann sich sicher sein, dass implementierende Klassen den Enumerator auch in einer solchen Weise implementieren, dass die Liste von vorn nach hinten durchlaufen werden.
Im übrigen macht das .Net Framework selber bei den diversen IEnumerable<T> extension methods implizite Annahmen über die Ausführung. Schaut euch einfach mal First, Last oder ElementAt an (welche intern eine Optimierung für den Fall haben, dass es sich um IList<T> handelt).
Dass eine enumeration ein nicht erwartetes Ergebnis hat, habe ich erst kürzlich selbst erlebt, einfach mal eine PriorityQueue enumerieren und sich wundern, dass die Elemente eine andere Reihenfolge haben, als wenn man Dequeue aufruft, bis sie leer ist
