Zakres swobody w budowaniu pętli for

Od jakiegoś czasu mnie zastanawia, czy są jakieś ograniczenia w postaci, jaką może przybrać pętla for? Czy iteracje muszą się ogólnie opierać na operacjach na liczbach całkowitych, czy też można sobie przybrać dowolne typy o ile zawartość nawiasu zachowa postać "przypisanie wartości początkowej; warunek kontynuowania, modyfikacja zmiennej"? Czy stoi coś na przeszkodzie, aby w pętli wykorzystać zmienne łańcuchowe, znakowe, zmiennoprzecinkowe czy też nawet całe kontenery, tak jak to pokazano poniżej?

for (string s = ""; !s.Equals("aaaaa"); s+="a")
{
}

for (double d = 31; d > 18; d *= 0,87)
{
}

for (char ch = 'a'; ch!='z'; ch++)
{
}

for (Arraylist lst = new Arraylist(5); lst[4]==null; lst.Add(new Object()))
{
}

Albo pójdźmy nawet dalej, czy można teoretycznie stworzyć sobie całą klasę specjalnie na potrzeby pętli for i potem wykorzystywać jej instancje, tak jak poniżej?

public class Iterator
{
	public Iterator(int k)
	{
		wartosc = 0;
		koniec = k;
		nadal = true;
	}
	public void zwieksz()
	{
		wartosc++;
		if (wartosc > koniec) nadal = false;
	}
	public int wartosc;
	public int koniec;
	public bool nadal;
}

for (Iterator it = new Iterator(10); it.nadal; it.zwieksz())
{
}

Możesz zrobić wszystko to, co przedstawiłeś. Musisz się jedynie zastanowić gdzie leży granica pomiędzy zwięzłością kodu, a jego czytelnością. Pętle for z pustym ciałem to nie jest IMO najlepsza praktyka w C# (w C czy C++ można je jeszcze przeboleć).

I tak np. jedną z tych konstrukcji zamieniłbym na:

string s = string.Empty;

while (s != "aaaaa")
    s += "a";

Nie korzystaj z ArrayList. To przeżytek, czasy .NET 1.1 bez generyków.

Albo pójdźmy nawet dalej, czy można teoretycznie stworzyć sobie całą klasę specjalnie na potrzeby pętli for i potem wykorzystywać jej instancje, tak jak poniżej?

Coś takiego już w C# i .NET istnieje i nazywa się "enumerator". Ba, uznano, że taka wersja pętli for będzie używana często i tak powstało foreach.

Mniej więcej to co twoja klasa Iterator robi interfejs IEnumerable. (ściślej: interfejs nic nie robi, ale klasa go implementująca)